每日精品文章2017_0106_01

微信爲什麼不丟消息?:

一、報文類型 im的客戶端與服務器通過發送報文(也就是網絡包)來完成消息的傳遞,報文分爲三種 請求報文(request,後簡稱爲爲R)
應答報文(acknowledge,後簡稱爲A) 通知報文(notify,後簡稱爲N),這三種報文的解釋如下:

這裏寫圖片描述
R:客戶端主動發送給服務器的報文 A:服務器被動應答客戶端的報文,一個A對應一個R N:服務器主動發送給客戶端的報文

二、普通消息投遞流程 用戶A給用戶B發送一個“你好”,流程如下:

1)client-A向im-server發送一個消息請求包,即msg:R
2)im-server在成功處理後,回覆client-A一個消息響應包,即msg:A
3)如果此時client-B在線,則im-server主動向client-B發送一個消息通知包,即msg:N(當然,如果client-B不在線,則消息會存儲離線)

三、上述消息投遞流程出現的問題
從流程圖中容易看到,發送方client-A收到msg:A後,只能說明im-server成功接收到了消息,並不能說明client-B接收到了消息。在若干場景下,可能出現msg:N包丟失,且發送方client-A完全不知道,例如:
1)服務器崩潰,msg:N包未發出 2)網絡抖動,msg:N包被網絡設備丟棄 3)client-B崩潰,msg:N包未接收
結論是悲觀的:接收方client-B是否有收到msg:N,發送方client-A完全不可控,那怎麼辦呢?

四、應用層確認+im消息可靠投遞的六個報文
upd是一種不可靠的傳輸層協議,tcp是一種可靠的傳輸層協議,tcp是如何做到可靠的?答案是:超時、重傳、確認。
要想實現應用層的消息可靠投遞,必須加入應用層的確認機制,即:要想讓發送方client-A確保接收方client-B收到了消息,必須讓接收方client-B給一個消息的確認,這個應用層的確認的流程,與消息的發送流程類似:
![這裏寫圖片描述](https://img-blog.csdn.net/20170106101101346?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZ3F3ZnVzZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
4)client-B向im-server發送一個ack請求包,即ack:R
5)im-server在成功處理後,回覆client-B一個ack響應包,即ack:A
6)則im-server主動向client-A發送一個ack通知包,即ack:N
至此,發送“你好”的client-A,在收到了ack:N報文後,才能確認client-B真正接收到了“你好”。
會發現,一條消息的發送,分別包含(上)(下)兩個半場,即msg的R/A/N三個報文,ack的R/A/N三個報文,一個應用層即時通訊消息的可靠投遞,共涉及6個報文,這就是im系統中消息投遞的最核心技術。

五、可靠消息投遞存在什麼問題
期望六個報文完成消息的可靠投遞,但實際情況,msg:N,ack:N這兩個報文都可能丟失(原因如第二章所述,可能是服務器奔潰、網絡抖動、或者客戶端奔潰),此時client-A都收不到期待的ack:N報文,即client-A不能確認client-B是否收到“你好”,但這兩個報文的丟失對應的業務影響又大有不同:
1)msg:N包丟失,業務結果是client-B沒有收到消息
2)ack:N包丟失,業務結果是client-B收到了消息,只是client-A不知道而已 那怎麼辦呢?

六、消息的超時與重傳
client-A發出了msg:R,收到了msg:A之後,在一個期待的時間內,如果沒有收到ack:N,client-A會嘗試將msg:R重發。可能client-A同時發出了很多消息,故client-A需要在本地維護一個等待ack隊列,並配合timer超時機制,來記錄哪些消息沒有收到ack:N,以定時重發。

一旦收到了ack:N,說明client-B收到了“你好”消息,對應的消息將從“等待ack隊列”中移除。

七、消息的重傳存在什麼問題 第五章提到過,msg:N,ack:N都有可能丟失:
1)msg:N報文丟失,說明client-B之前壓根沒有收到“你好”報文,超時與重傳機制十分有效
2)ack:N報文丟失,說明client-B之前已經收到了“你好”報文(只是client-A不知道而已),超時與重傳機制將導致client-B收到重複的消息,那怎麼辦呢?

八、消息的去重
解決方法也很簡單,由發送方client-A生成一個消息去重的msgid,保存在“等待ack隊列”裏,同一條消息使用相同的msgid來重傳,供client-B去重,而不影響用戶體驗。

九、其他 1)上述設計理念,由客戶端重傳,可以保證服務端無狀態性(架構設計基本準則)
2)如果client-B不在線,im-server保存了離線消息後,要僞造ack:N發送給client-A

十、總結 1)im系統是通過超時、重傳、確認、去重的機制來保證消息的可靠投遞,不丟不重
2)一個“你好”的發送,包含上半場msg:R/A/N與下半場ack:R/A/N的6個報文
3)im系統難以做到系統層面的不丟不重,只能做到業務層面的不丟不重
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章