前言
在解决了上一次关于超级话题积分bug后，又接到超级话题签到提醒的产品需求。这是一篇偏于技术实现的文章，讲述的比较笼统，业务围绕超级话题的签到提醒进行展开。如果，您对超级话题签到提醒的技术背景与实现感兴趣，那么这篇文章希望对你有帮助。产品
最近，在忙活超级话题的签到提醒产品的开发。首先，这是第一次比较热切的关注用户反应的产品。虽然说，对于产品的参与和认知并没有多么深入的理解，但是愈发的觉得这件事很有意识，也更想参与其中。超级话题打破了传统话题的模式，以社区的形式展现，提高用户互动与粘性。其中，签到是不可或缺的一项功能。然而在前期，签到功能在给用户带来了高回访的情况下，也有着苦恼。作为研发同学，更是备受折磨。为什么？产品总是拿着反馈中自称经签过但却莫名断签的用户 ID 找我排查问题所在。然而，几乎都是一些凌晨时分签到而次日未签的情形。尽管是这样，用户的反感也是无法消除的。
为了不再做反复的排查劳动，只好做了一个相关查询后台。
产品同学为了召回用户，提供话题的 UV 和 PV，提出了签到提醒的概念。
签到提醒会根据当前用户的签到行为，进行提醒私信的推送。目前为止，基本上每日需要提醒的量大约在 85w 左右。然而，在发送私信的过程中并非如此顺利。
技术
- 准备数据
- 发送私信
数据
超级话题提醒私信下发量：85W/日超级话题提醒倒流 UV：可观
下面的Redis服务中 Key 的曲线图，可以约等于下发的私信量：
[caption id="attachment_7406" align="aligncenter" width="501"]
超级话题签到提醒 redis-key 优美的曲线图[/caption]
问题
在形成上面的技术流程之前，也是经过了几番周折。- 单进程
- 批量调用
- 多进程 & 批量调用
在功能上线的第一天晚间，观察处理文件的进程“卡死”。
[caption id="attachment_7396" align="aligncenter" width="840"]
strace PHP 进程信息截图[/caption]
[caption id="attachment_7395" align="aligncenter" width="971"]
lsof PHP 进程信息截图[/caption]
从上面两图可以确定，PHP 进程卡死的愿意在于读取 MySQL 服务中。进过排查处理后，程序得以进入正常流程。
目前为止，每日的调用量完全可以满足所需要发送的私信量。
用户
用户对签到提醒的反馈还是非常不错的，有图为证：
总结
针对于这种需要长时间运行与调用外部资源的脚本，最重要的就行要进行好完善的异常处理机制。由于PHP脚本的异常处理并非强制的，如果处理不妥到，会导致进程直接终止，排查起来也很困难。同时，对于相关资源的监控也很重要。比如，当前机器的 CPU 资源，接口的平均响应时间，DB 服务的相应时间等等。以确定每次执行期间相关资源的健康状态。
文章来源：胡旭博客 => 自从有了她，再也不怕断签了：超级话题签到提醒
转载请注明出处，违者必究！
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于