2015年接到一個(gè)質(zhì)量工單任務(wù)气笙,情況是:一個(gè)預(yù)警業(yè)務(wù),有部分用戶反饋沒有收到應(yīng)該有的預(yù)警怯晕。分析了下項(xiàng)目源碼潜圃,發(fā)送的實(shí)現(xiàn)方法如下
- A部門提供一個(gè)名叫 send.php 的接口。
- B部門調(diào)用send.php接口舟茶,將需要發(fā)送的 uid名單post過來秉犹。
其中send.php邏輯如下
1. 解析B部門提交過來的uid列表
2. 循環(huán)調(diào)用第三方push接口給這些uid發(fā)push
3. 列表全部發(fā)送完,按協(xié)議響應(yīng)終止B的請(qǐng)求
寫到這里我想已經(jīng)有人知道問題所在稚晚,恩崇堵,先不寫了。
接著寫
問題出現(xiàn)在:send.php是A發(fā)起的http請(qǐng)求中同步進(jìn)行所有名單的push處理的客燕。
A調(diào)用send.php是如下的方式
curl "192.168.0.100/send.php" -m 10
即10秒超時(shí)鸳劳,若一個(gè)用戶發(fā)送push需要1s中,那么send.php發(fā)送10個(gè)用戶后也搓,A這邊curl的客戶端
就會(huì)斷開連接赏廓,這是在B的機(jī)器上看nginx日志就會(huì)出現(xiàn)499
的狀態(tài)碼。
但是按上面的條件也不只是能發(fā)送10個(gè)用戶傍妒,其實(shí)send.php這個(gè)腳本不一定已經(jīng)終止了幔摸,只是nginx已經(jīng)不管這個(gè)phpfpm進(jìn)程了。send.php 最終運(yùn)行時(shí)長(zhǎng)受 php.ini 和php-fpm.conf中的相關(guān)配置影響了颤练。
解決辦法:send.php不要同步進(jìn)行名單的發(fā)送既忆,只需要把名單存起來,另外單獨(dú)開cli的任務(wù)腳本嗦玖,處理名單患雇。