長連線資料實時推送方案(iOS)
由於業務需求，需要實現實時獲取服務端更新的資料功能，基於這個需求，進行調研及技術方案的實施，最終決定採用MQTT +ProtocolBuffer基於長連線的資料實時推送的方案；具體實現方案見本文； 本文包括三個部分：1.技術選型 2.技術方案實踐 3.未來優化方向
技術選型
在調研過程中，發現需求功能可以使用推送來實現，但最終經過各種考慮，發現自建長連線進行實時資料推送是最為貼合需求的實現方案；調研過程中，對推送廠家方案及本文方案做了對比，結果如下：
| 推送SDK | 整合APNs | 保持長連線 |
|---|---|---|
| 極光推送 | 是 | 是 |
| 個推 | 是 | 是 |
| 百度推送 | 是 | 否 |
| 騰訊信鴿 | 是 | 否 |
| 本文方案 | 否 | 是 |
從表格來看，本文方案不過是極光推送和個推的一種簡化版，完全可以使用極光推送和個推來實現，或者是使用推送來進行資料推送；但從需求具體來講，才更能體現本文方案的可行性及必要性；具體分析如下：
- 推送方案具有極大的不確定性，訊息丟失率比較高
- 極光推送和個推SDK採用了長連線的方式，但是長連線協議並不可知，且資料傳輸格式，連結存在狀態不受控制
- 自定方案，因採用
MQTT和Protocol Buffer兩種協議，對弱網情況相容較好，裝置效能要求相對較低，且對資料格式優化比較好，且連結狀態完全可控，可以實時監控到鏈路是否可用，對分析問題、解決問題有很大便利；
技術方案實踐
方案流程
整個技術方案大體流程如下圖：
在整個過程中，訊息的實時傳送靠推送後臺和長連線SDK建立的長連線來實現；而基於本方案實現的SDK則負責和推送後臺維持長連線的有效性以及維持長連線的優化功能；
詳細流程中涉及到的互動方和互動流程參照下圖：
方案架構
在整個資料實時傳送方案中，涉及到長連線的建立維護、通訊資料按協議封裝、業務資料封裝及優化等功能，在此對整個方案進行整理，整理之後結構如下：
在整體結構中，分為業務層、應用層、傳輸層、和網路層，其中業務層、應用層、傳輸層組成了資料實時推送服務的SDK； 1.業務層：主要處理業務資料，訊息儲存，訊息丟失、重複處理，以及資料格式轉化等； 2.應用層：該層為整個SDK的核心層，封裝了
MQTT協議，以及對斷線重連、安全連線等； 3.傳輸層：該層主要核心為呼叫系統API實現長連線、資料封包、超時重發等處理；
下面對整個SDK架構層級，以及各層級間包含的模組進行詳細整理及說明；如下圖：
業務層 該層主要解決，資料格式轉化，訊息丟失、重複，訊息儲存，資料統計等功能；下邊對這些功能逐一介紹：
- 資料格式轉化： 此模組負責將
ProtocolBuffer型別的資料轉化成JSON資料 - 訊息重複、丟失處理：此模組會根據規則判斷收到的訊息是否重複，或者在收到該資訊之前是否丟過訊息，經過處理之後，如果重複則不再傳給業務方，如果有訊息丟失也將告訴業務方，以便業務方處理相關情況；
- 訊息儲存：根據一定快取策略對訊息進行短時間儲存，以便解決訊息判重、處理丟失等問題；
- 資料統計：此模組將對訊息進行統計，區分重複、丟失等情況，並將資料上報伺服器，方便驗證整個方案的可行性和問題等；
應用層 該層命名的來源主要來自於MQTT，因MQTT屬於業務層協議，該層的操作絕大部分是對協議的實現以及優化；主要包含 MQTT的實現、心跳機制、斷線重連機制、連結狀態管理等；
MQTT的實現：此模組主要採用三方庫MQTTClient，該三方庫對MQTT協議進行了完整封裝，目前階段，該方案對MQTT協議的實現暫時依賴該庫；- 心跳機制：因專案初期，且方案有待驗證，此模組暫時使用較為簡單的固定心跳機制，設定心跳間隔為60S；對於該心跳間隔，因不確定個運營商的NAT超時時間，故對心跳間隔設定較小，此間隔可能引起手機流量、電量消耗的增加，此模組為後續重點優化模組；
- 斷線重連機制：因存在網路切換、行動網路基站變更、以及網路斷開等問題，特提供斷線重連機制，此機制目前採用方案為：以2的n次方為時間間隔進行重連，n為重連次數，當n等於6時不再重試；
- 連結狀態管理：此模組負責對應用前臺、後臺不同狀態情況下，連結的處理情況的管理；
傳輸層 該層主要為呼叫系統API對Socket資料進行拼接組裝，以及發起連線、關閉連線等操作；
對於該方案的具體模組，以上均已介紹完畢，以下是對該方案大致流程的梳理，如下圖：
此流程展示出了SDK從建立連結、接收資料，經由TCP資料包處理、MQTT通訊資料解析，到ProtocolBuffer資料格式處理等大致流程；到此，整個現有方案結束；
未來優化方向
考慮到移動端手機電量、流量、及網路連線不穩定的情況，上述方案顯然不是完美的方案，針對上述方案，現有以下規劃：
智慧心跳策略
因心跳是保證連線存活的必要手段，心跳的存在毋庸置疑，但是心跳的存在，也必定會增加電量、流量的消耗；在此針對該方案的心跳策略提出以下針對性優化設想，特提出以下方案---智慧心跳策略；大致流程如下圖：
斷線重連機制優化
因有可能發生伺服器異常，造成客戶端集體掉線的情況，客戶端會立刻發起重連，在使用者量較小的情況下，客戶端集體重連對於服務端可以承受，但當用戶量級達到一定數量，大量客戶端的重連，可能就會產生重連風暴，直接導致服務端再次出現異常，因此對於重連機制也應考慮一個比較合適、能避免重連風暴的策略；
網路連線優化
IP直連、鏈路複用、控制傳輸包大小等、