1. 程式人生 > >長連線資料實時推送方案(iOS)

長連線資料實時推送方案(iOS)

原文連結:www.jianshu.com/p/7e97af441…

由於業務需求,需要實現實時獲取服務端更新的資料功能,基於這個需求,進行調研及技術方案的實施,最終決定採用MQTT +ProtocolBuffer基於長連線的資料實時推送的方案;具體實現方案見本文; 本文包括三個部分:1.技術選型 2.技術方案實踐 3.未來優化方向


技術選型

在調研過程中,發現需求功能可以使用推送來實現,但最終經過各種考慮,發現自建長連線進行實時資料推送是最為貼合需求的實現方案;調研過程中,對推送廠家方案及本文方案做了對比,結果如下:

推送SDK 整合APNs 保持長連線
極光推送
個推
百度推送
騰訊信鴿
本文方案

從表格來看,本文方案不過是極光推送和個推的一種簡化版,完全可以使用極光推送和個推來實現,或者是使用推送來進行資料推送;但從需求具體來講,才更能體現本文方案的可行性及必要性;具體分析如下:

  1. 推送方案具有極大的不確定性,訊息丟失率比較高
  2. 極光推送和個推SDK採用了長連線的方式,但是長連線協議並不可知,且資料傳輸格式,連結存在狀態不受控制
  3. 自定方案,因採用MQTTProtocol Buffer兩種協議,對弱網情況相容較好,裝置效能要求相對較低,且對資料格式優化比較好,且連結狀態完全可控,可以實時監控到鏈路是否可用,對分析問題、解決問題有很大便利;

技術方案實踐

方案流程

整個技術方案大體流程如下圖:

推送流程圖.png

在整個過程中,訊息的實時傳送靠推送後臺和長連線SDK建立的長連線來實現;而基於本方案實現的SDK則負責和推送後臺維持長連線的有效性以及維持長連線的優化功能;

詳細流程中涉及到的互動方和互動流程參照下圖:

詳細互動流程.png

方案架構

在整個資料實時傳送方案中,涉及到長連線的建立維護、通訊資料按協議封裝、業務資料封裝及優化等功能,在此對整個方案進行整理,整理之後結構如下:

推送服務SDK層級.png

在整體結構中,分為業務層、應用層、傳輸層、和網路層,其中業務層、應用層、傳輸層組成了資料實時推送服務的SDK; 1.業務層:主要處理業務資料,訊息儲存,訊息丟失、重複處理,以及資料格式轉化等; 2.應用層:該層為整個SDK的核心層,封裝了MQTT協議,以及對斷線重連、安全連線等; 3.傳輸層:該層主要核心為呼叫系統API實現長連線、資料封包、超時重發等處理;

下面對整個SDK架構層級,以及各層級間包含的模組進行詳細整理及說明;如下圖:

長連線方案結構圖.png

業務層 該層主要解決,資料格式轉化,訊息丟失、重複,訊息儲存,資料統計等功能;下邊對這些功能逐一介紹:

  1. 資料格式轉化: 此模組負責將ProtocolBuffer型別的資料轉化成JSON資料
  2. 訊息重複、丟失處理:此模組會根據規則判斷收到的訊息是否重複,或者在收到該資訊之前是否丟過訊息,經過處理之後,如果重複則不再傳給業務方,如果有訊息丟失也將告訴業務方,以便業務方處理相關情況;
  3. 訊息儲存:根據一定快取策略對訊息進行短時間儲存,以便解決訊息判重、處理丟失等問題;
  4. 資料統計:此模組將對訊息進行統計,區分重複、丟失等情況,並將資料上報伺服器,方便驗證整個方案的可行性和問題等;

應用層 該層命名的來源主要來自於MQTT,因MQTT屬於業務層協議,該層的操作絕大部分是對協議的實現以及優化;主要包含 MQTT的實現、心跳機制、斷線重連機制、連結狀態管理等;

  1. MQTT的實現:此模組主要採用三方庫MQTTClient,該三方庫對MQTT協議進行了完整封裝,目前階段,該方案對MQTT協議的實現暫時依賴該庫;
  2. 心跳機制:因專案初期,且方案有待驗證,此模組暫時使用較為簡單的固定心跳機制,設定心跳間隔為60S;對於該心跳間隔,因不確定個運營商的NAT超時時間,故對心跳間隔設定較小,此間隔可能引起手機流量、電量消耗的增加,此模組為後續重點優化模組;
  3. 斷線重連機制:因存在網路切換、行動網路基站變更、以及網路斷開等問題,特提供斷線重連機制,此機制目前採用方案為:以2的n次方為時間間隔進行重連,n為重連次數,當n等於6時不再重試;
  4. 連結狀態管理:此模組負責對應用前臺、後臺不同狀態情況下,連結的處理情況的管理;

傳輸層 該層主要為呼叫系統API對Socket資料進行拼接組裝,以及發起連線、關閉連線等操作;

對於該方案的具體模組,以上均已介紹完畢,以下是對該方案大致流程的梳理,如下圖:

資料處理流程.png

此流程展示出了SDK從建立連結、接收資料,經由TCP資料包處理、MQTT通訊資料解析,到ProtocolBuffer資料格式處理等大致流程;到此,整個現有方案結束;


未來優化方向

考慮到移動端手機電量、流量、及網路連線不穩定的情況,上述方案顯然不是完美的方案,針對上述方案,現有以下規劃:

智慧心跳策略

因心跳是保證連線存活的必要手段,心跳的存在毋庸置疑,但是心跳的存在,也必定會增加電量、流量的消耗;在此針對該方案的心跳策略提出以下針對性優化設想,特提出以下方案---智慧心跳策略;大致流程如下圖:

智慧心跳策略.png

斷線重連機制優化

因有可能發生伺服器異常,造成客戶端集體掉線的情況,客戶端會立刻發起重連,在使用者量較小的情況下,客戶端集體重連對於服務端可以承受,但當用戶量級達到一定數量,大量客戶端的重連,可能就會產生重連風暴,直接導致服務端再次出現異常,因此對於重連機制也應考慮一個比較合適、能避免重連風暴的策略;

網路連線優化

IP直連、鏈路複用、控制傳輸包大小等、