php后臺(tái)推送消息，有時(shí)候消息會(huì)推送不成功
然后呢我為了，測試循環(huán)的1000消息推送，如果發(fā)送的消息量大一些。循環(huán)到某一段的時(shí)候就會(huì)找不到uid，如果發(fā)送的消息簡單，比如就發(fā)送哥 1或者2? 1000條消息可以全部順利發(fā)送成，
?
[attach]1328[/attach]
如果發(fā)送失敗，也應(yīng)該return data ===false啊? 為什么會(huì)返回201 找不到這個(gè)uid呢
5個(gè)回答
1、201這個(gè)返回碼，這不是你圖示的示例代碼定義的嗎？ 不一定非返回201啊
2、測試用了什么協(xié)議以及發(fā)送了多大的數(shù)據(jù)？根據(jù)你目前的上下文，只能推測可能的原因是：
發(fā)送數(shù)據(jù)過大，超過了連接能夠接收的最大包長，默認(rèn)為10MB，導(dǎo)致連接被關(guān)閉，即uid離線；
當(dāng)然也不排除你客戶端自身的原因造成的中途離線。
總結(jié)下，僅供參考：
1、題示總體現(xiàn)象表現(xiàn)為客戶端中途或提早離線。
2、你這段代碼看上去很熟，很像一段 “異步推送” 代碼片段，你推送的測試是直接在服務(wù)端調(diào)用推送接口，還是從獨(dú)立客戶端先轉(zhuǎn)推到服務(wù)端而后再推給對(duì)向客戶端？
如果是直接在服務(wù)端調(diào)用推送接口【比如赤裸的調(diào)用sendMessageByUid()】，那我第一次的說法就不對(duì)了，因?yàn)槟莻€(gè)是wm底層接收端的判斷邏輯。另外即便是獨(dú)立的客戶端轉(zhuǎn)推，也不會(huì)影響到你對(duì)向的連接客戶端。
3、假如你是在服務(wù)端直接推送，對(duì)你提及的循環(huán)請(qǐng)求推送接口發(fā)送大數(shù)據(jù)這種情況，若由于網(wǎng)絡(luò)原因客戶端未來得及接收數(shù)據(jù)，則會(huì)導(dǎo)致數(shù)據(jù)積壓在應(yīng)用層的發(fā)送緩沖區(qū)，最終導(dǎo)致丟包，但這并不會(huì)導(dǎo)致與客戶端的連接斷開，即不會(huì)離線。
4、根據(jù)你描述的早上這情況，我說不好，你自己觀察下框架日志以及記錄下業(yè)務(wù)日志，甚至源碼調(diào)試下都不難的。
5、推送消息失敗的可能原因一般是：
(1) 客戶端主動(dòng)斷開
(2) 沒有設(shè)置必要的心跳，防火墻干掉不活躍的連接
(3) 客戶端發(fā)送的數(shù)據(jù)包非法，服務(wù)端主動(dòng)關(guān)閉連接
(4) 應(yīng)用層發(fā)送緩沖區(qū)爆滿
(5) 網(wǎng)絡(luò)原因
(6) 其他原因
[attach]1329[/attach]
明明消息推送成功，? 他卻走到返回201這一步，怎么這么奇葩
。。
