2015年接到一个质量工单任务，情况是：一个预警业务，有部分用户反馈没有收到应该有的预警。分析了下项目源码，发送的实现方法如下
- A部门提供一个名叫 send.php 的接口。
- B部门调用send.php接口，将需要发送的 uid名单post过来。
其中send.php逻辑如下
1. 解析B部门提交过来的uid列表
2. 循环调用第三方push接口给这些uid发push
3. 列表全部发送完，按协议响应终止B的请求
写到这里我想已经有人知道问题所在，恩，先不写了。
接着写
问题出现在：send.php是A发起的http请求中同步进行所有名单的push处理的。
A调用send.php是如下的方式
curl "192.168.0.100/send.php" -m 10
即10秒超时，若一个用户发送push需要1s中，那么send.php发送10个用户后，A这边curl的客户端就会断开连接，这是在B的机器上看nginx日志就会出现499的状态码。
但是按上面的条件也不只是能发送10个用户，其实send.php这个脚本不一定已经终止了，只是nginx已经不管这个phpfpm进程了。send.php 最终运行时长受 php.ini 和php-fpm.conf中的相关配置影响了。
解决办法：send.php不要同步进行名单的发送，只需要把名单存起来，另外单独开cli的任务脚本，处理名单。
