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