陌陌通訊協議的學習

陌陌發展剛開始由於規模小，30-40W的連線數（包括Android後臺長連線使用者），也使用XMPP；由於XMPP的缺點：流量大（基於XML），不可靠（為傳統固定網路設計，沒有考慮WIFI/2G/3G/地鐵/電梯等複雜網路場景），互動複雜（登陸需5-6次，尤其是TLS握手）；XMPP丟訊息的根本原因：服務端和客戶端處於“半關閉”狀態，客戶端假連線狀態，服務端有收不到回執；Server端連線層和邏輯層程式碼沒有解耦分離，常常重啟導致不可用。

訊息中轉：

連線層（Connector連結叢集）

• 連線層的作用：只做訊息轉發
• 設計原則簡單/非同步
• 允許隨時重啟更新/只允許晚上重啟/不允許重啟斷線
• 單臺壓測試連線數70W；現狀：5億使用者，月活5000W+，連線數1200W+；

邏輯層（Logic邏輯叢集）

• 使用者會話驗證
• 訊息存取
• 非同步佇列
• 隨時重啟

通訊協議設計：

• 安全性要求
• 流量要求
• 傳輸要求可靠（不會丟訊息）
• 高效（弱網路快速的收發）
• 易於擴充套件

通訊協議：

• 常見協議XMPP/SIP
• 缺點：流量大，不可靠，互動複雜

採用私有通訊協議，目標：

• 高效，弱網路快速收發；
• 可靠,不會丟訊息；
• 易於擴充套件；
• 參考協議格式：REDIS協議；

Redis協議：

下面都是用Redis協議來描述邏輯

Read Redis Command

基於佇列的訊息協議

基於佇列的互動

• 傳統的IM協議
• 前提是基於網線、WiFI，網路延遲極小
• 行動網路下，互動及其費時，伺服器要維護每個狀態容易出錯

基於版本號的訊息協議

基於版本號的互動

針對弱網路的優化協議

• 訊息通過版本號維護順序
• 新訊息到達，Server只負責push通知
• Client收到輕量的msg-psh後發生同步請求
• Server按照版本號連續傳送msg
• Client告訴Server收到的最後的版本

監控

• 核心的長連線只用於傳輸輕量的實時資料，圖片、語音等都開新的TCP或HTTP連線；一切就緒後，最重要的就是監控，寫一個APP檢視所有的運營狀態，每天觀察；

如何選擇最優路線智慧路由、連線策略：

多埠、雙協議支援，應對移動閘道器代理的埠限制

• 支援TCP、HTTP兩種協議
• 根據備選IP列表進行併發測速（IP+埠+協議）
• 後端根據終端連線情況，定時更新終端的備選IP列表
• 終端在連線空閒時上報測速資料，便於後端決策
• TCP協議不通，自動切換到http
• 優先使用最近可用IP
• 併發測速，根據終端所處的位置下發多組IP、PORT，只用IP，不用域名，手機上的DNS50%不準