本文內容和編寫思路是基於鄧昀澤的“大規模併發IM服務架構設計”、“IM的弱網場景優化”兩文的提綱進行的，感謝鄧昀澤的無私分享。
1、引言
接上篇《一套億級用戶的IM架構技術乾貨(上篇)：整體架構、服務拆分等》，本文主要聚焦這套億級用戶的IM架構的一些比較細節但很重要的熱門問題上，比如：消息可靠性、消息有序性、數據安全性、移動端弱網問題等。
以上這些熱門IM問題每個話題其實都可以單獨成文，但限於文章篇幅，本文不會逐個問題詳細深入地探討，主要以拋磚引玉的方式引導閱讀者理解問題的關鍵，並針對問題提供專項研究文章鏈接，方便有選擇性的深入學習。希望本文能給你的IM開發帶來一些益處。
2、系列文章
爲了更好以進行內容呈現，本文拆分兩了上下兩篇。
本文是2篇文章中的第2篇：
本篇主要聚焦這套億級用戶的IM架構的一些比較細節但很重要的熱門問題上。
3、消息可靠性問題
消息的可靠性是IM系統的典型技術指標，對於用戶來說，消息能不能被可靠送達（不丟消息），是使用這套IM的信任前提。
換句話說，如果這套IM系統不能保證不丟消息，那相當於發送的每一條消息都有被丟失的概率，對於用戶而言，一定會不會“放心”地使用它，即“不信任”這套IM。
從產品經理的角度來說，有這樣的技術障礙存在，再怎麼費力的推廣，最終用戶都會很快流失。所以一套IM如果不能保證消息的可靠性，那問題是很嚴重的。
PS：如果你對IM消息可靠性的問題還沒有一個直觀的映象的話，通過《零基礎IM開發入門(三)：什麼是IM系統的可靠性？》這篇文章可以通俗易懂的理解它。
如上圖所示，消息可靠性主要依賴2個邏輯來保障：
- 1）上行消息可靠性；
- 2）下行消息可靠性。
1）針對上行消息的可靠性，可以這樣的思路來處理：
用戶發送一個消息（假設協議叫PIMSendReq），用戶要給這個消息設定一個本地ID，然後等待服務器操作完成給發送者一個PIMSendAck（本地ID一致），告訴用戶發送成功了。
如果等待一段時間，沒收到這個ACK，說明用戶發送不成功，客戶端SDK要做重試操作。
2）針對下行消息的可靠性，可以這樣的思路來處理：
服務收到了用戶A的消息，要把這個消息推送給B、C、D 3個人。假設B臨時掉線了，那麼在線推送很可能會失敗。
因此確保下行可靠性的核心是：在做推送前要把這個推送請求緩存起來。
這個緩存由存儲系統來保證，MsgWriter要維護一個（離線消息列表），用戶的一條消息，要同時寫入B、C、D的離線消息列表，B、C、D收到這個消息以後，要給存儲系統一個ACK，然後存儲系統把消息ID從離線消息列表裏拿掉。
針對消息的可靠性問題，具體的解決思路還可以從另一個維度來考慮：即實時消息的可靠性和離線消息的可靠性。
有興趣可以深入讀一讀這兩篇：
而對於離線消息的可靠性來說，單聊和羣聊又有很大區別，有關羣聊的離線消息可靠投遞問題，可以深入讀一讀《IM開發乾貨分享：如何優雅的實現大量離線消息的可靠投遞》。
4、消息有序性問題
消息的有序性問題是分佈式IM系統中的另一個技術“硬骨頭”。
因爲是分佈式系統，客戶端和服務器的時鐘可能是不同步的。如果簡單依賴某一方的時鐘，就會出現大量的消息亂序。
比如只依賴客戶端的時鐘，A比B時間晚30分鐘。所有A給B發消息，然後B給A回覆。
發送順序是：
客戶端A：“XXX”
客戶端B：“YYY”
接收方的排序就會變成：
客戶端B：“YYY”
客戶端A：“XXX”
因爲A的時間晚３０分鐘，所有A的消息都會排在後面。
如果只依賴服務器的時鐘，也會出現類似的問題，因爲2個服務器時間可能也不一致。雖然客戶端A和客戶端B時鐘一致，但是A的消息由服務器S1處理，B的消息由服務器S2處理，也會導致同樣消息亂序。
爲了解決這種問題，我的思路是通過可以做這樣一系列的操作來實現。
1）服務器時間對齊：
這部分就是後端運維的鍋了，由系統管理員來儘量保障，沒有別的招兒。
2）客戶端通過時間調校對齊服務器時間：
比如：客戶端登錄以後，拿客戶端時間和服務器時間做差值計算，發送消息的時候考慮這部分差值。
在我的im架構裏，這個能把時間對齊到100ms這個級，差值再小的話就很困難了，因爲協議在客戶端和服務器之間傳遞速度RTT也是不穩定的（網絡傳輸存在不可控的延遲風險嘛）。
3）消息同時帶上本地時間和服務器時間：
具體可以這樣的處理：排序的時候，對於同一個人的消息，按照消息本地時間來排；對於不同人的消息，按照服務器時間來排，這是插值排序算法。
PS：關於消息有序性的問題，顯然也不是上面這三兩句話能講的清楚，如果你想更通俗一理解它，可以讀一讀《零基礎IM開發入門(四)：什麼是IM系統的消息時序一致性？》。
另外：從技術實踐可行性的角度來說，《一個低成本確保IM消息時序的方法探討》、《如何保證IM實時消息的“時序性”與“一致性”？》這兩篇中的思路可以借鑑一下。
實際上，消息的排序問題，還可以從消息ID的角度去處理（也就是通過算法讓消息ID產生順序性，從而根據消息ID就能達到消息排序的目的）。
有關順序的消息ID算法問題，這兩篇非常值得借鑑：《IM消息ID技術專題(一)：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》、《IM消息ID技術專題(三)：解密融雲IM產品的聊天消息ID生成策略》，我就不廢話了。
5、消息已讀同步問題
消息的已讀未讀功能，如下圖所示：
上圖就是釘釘中的已讀未讀消息。這在企業IM場景下非常有用（因爲做領導的都喜歡，你懂的）。
已讀未讀功能，對於一對一的單聊消息來說，還比較好理解：就是多加一條對應的回執息（當用戶閱讀這條消息時發回）。
但對於羣聊這說，這一條消息有多少人已讀、多少人未讀，想實現這個效果，那就真的有點麻煩了。對於羣聊的已讀未讀功能實現邏輯，這裏就不展開了，有興趣可以讀一下這篇《IM羣聊消息的已讀回執功能該怎麼實現？》。
迴歸到本節的主題“已讀同步”的問題，這顯示難度又進一級，因爲已讀未讀回執不只是針對“賬號”，現在還要細分到“同一賬號在不同端登陸”的情況，對於已讀回執的同步邏輯來說，這就有點複雜化了。
在這裏，根據我這邊IM架構的實踐經驗，提供一些思路。
具體來說就是：用戶可能有多個設備登錄同一個賬戶（比如：Web PC和移動端同時登陸），這種情況下的已讀未讀功能，就需要來實現已讀同步，否則在設備1看過的消息，設備2看到依然是未讀消息，從產品的角度來說，這就影響用戶體驗了。
對於我的im架構來說，已讀同步主要依賴2個邏輯來保證：
- 1）同步狀態維護，爲用戶的每一個Session，維護一個時間戳，保存最後的讀消息時間；
- 2）如果用戶打開了某個Session，且用戶有多個設備在線，發送一條PIMSyncRead消息，通知其它設備。
6、數據安全問題
6.1 基礎
IM系統架構中的數據安全比一般系統要複雜一些，從通信的角度來說，它涉及到socket長連接通信的安全性和http短連接的兩重安全性。而隨着IM在移動端的流行，又要在安全性、性能、數據流量、用戶體驗這幾個維度上做權衡，所以想要實現一套完善的IM安全架構，要面臨的挑戰是很多的。
IM系統架構中，所謂的數據安全，主要是通信安全和內容安全。
6.2 通信安全
所謂的通信安全，這就要理解IM通信的服務組成。
目前來說，一個典型的im系統，主要由兩種通信服務組成：
- 1）socket長連接服務：技術上也就是多數人耳熟能詳的網絡通信這一塊，再細化一點也就是tcp、udp協議這一塊；
- 2）http短連接服務：也就是最常用的http rest接口那些。
對於提升長連接的安全性思路，可以深入閱讀《通俗易懂：一篇掌握即時通訊的消息傳輸安全原理》。另外，微信團隊分享的《微信新一代通信安全解決方案：基於TLS1.3的MMTLS詳解》一文，也非常有參考意義。
如果是通信安全級別更高的場景，可以參考《即時通訊安全篇（二）：探討組合加密算法在IM中的應用》，文中關於組合加密算法的使用思路非常不錯。
至於短連接安全性，大家就很熟悉了，開啓https多數情況下就夠用了。如果對於https不甚瞭解，可以從這幾篇開始：《一文讀懂Https的安全性原理、數字證書、單項認證、雙項認證等》、《即時通訊安全篇（七）：如果這樣來理解HTTPS，一篇就夠了》。
6.3 內容安全
這個可能不太好理解，上面既然實現了通信安全，那爲什麼還要糾結“內容安全”？
我們瞭解一下所謂的密碼學三大作用：加密（ Encryption）、認證（Authentication），鑑定（Identification） 。
詳細來說就是：
加密：防止壞人獲取你的數據。
認證：防止壞人修改了你的數據而你卻並沒有發現。
鑑權：防止壞人假冒你的身份。
在上節中，惡意攻擊者如果在通信環節繞開或突破了“鑑權”、“認證”，那麼依賴於“鑑權”、“認證”的“加密”，實際上也有可有被破解。
針對上述問題，那麼我們需要對內容進行更加安全獨立的加密處理，就這是所謂的“端到端加密”（E2E）。
比如，那個號稱無法被破解的IM——Telegram，實際上就是使用了端到端加密技術。
關於端到端加密，這裏就不深入探討，這裏有兩篇文章有興趣地可以深入閱讀：
7、雪崩效應問題
在分佈式的IM架構中，存在雪崩效應問題。
我們知道，分佈式的IM架構中，爲了高可用性，用戶每次登陸都是根據負載均衡算法分配到不同的服務器。那麼問題就來了。
舉個例子：假設有5個機房，其中A機房故障，導致這個機房先前服務的用戶都跑去B機房。B機房不堪重負也崩潰了，A+B的用戶跑去機房C，連鎖反應會導致所有服務掛掉。
防止雪崩效應需要在服務器架構，客戶端鏈接策略上有一些配合的解決方案。服務器需要有限流能力作爲基礎，主要是限制總服務用戶數和短時間鏈接用戶數。
在客戶端層面，發現服務斷開之後要有一個策略，防止大量用戶同一時間去鏈接某個服務器。
通常有2種方案：
- 1）退避：重連之間設置一個隨機的間隔；
- 2）LBS：跟服務器申請重連的新的服務器IP，然後由LBS服務去降低短時間分配到同一個服務器的用戶量。
這2種方案互不衝突，可以同時做。
8、弱網問題
8.1 弱網問題的原因
鑑於如今IM在移動端的流行，弱網是很常態的問題。電梯、火車上、開車、地鐵等等場景，都會遇到明顯的弱網問題。
那麼爲什麼會出現弱網問題？
要回答這個問題，那就需要從無線通信的原理上去尋找答案。
因爲無線通信的質量受制於很多方面的因素，比如：無線信號強弱變化快、信號干擾、通信基站分佈不均、移動速度太快等等。要說清楚這個問題，那就真是三天三夜都講不完。
有興趣的讀者，一定要仔細閱讀下面這幾篇文章，類似的跨學科科譜式文章並不多見：
《IM開發者的零基礎通信技術入門(十一)：爲什麼WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
弱網問題是移動端APP的必修課，下面這幾篇總結也值得借鑑：
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
8.2 IM針對弱網問題的處理
對於IM來說，弱網問題並不是很複雜，核心是做好消息的重發、排序以及接收端的重試。
爲了解決好弱網引發的IM問題，通常可以通過以下手段改善：
- 1）消息自動重發；
- 2）離線消息接收；
- 3）重發消息排序；
- 4）離線指令處理。
下面將逐一展開討論。
8.3 消息自動重發
坐地鐵的時候，經常遇到列車開起來以後，網絡斷開，發送消息失敗。
這時候產品有2種表現形式：
- a、直接告訴用戶發送失敗；
- b、保持發送狀態，自動重試3-5次（3分鐘）以後告訴用戶發送失敗。
顯然：自動重試失敗以後再告訴用戶發送失敗體驗要好很多。尤其是在網絡閃斷情況下，重試成功率很高，很可能用戶根本感知不到有發送失敗。
從技術上：客戶端IMSDK要把每條消息的狀態監控起來。發送消息不能簡單的調用一下網絡發送請求，而是要有一個狀態機，管理幾個狀態：初始狀態，發送中，發送失敗，發送超時。對於失敗和超時的狀態，要啓用重試機制。
這裏還有一篇關於重試機制設計的討論帖子，有興趣可以看看：《完全自已開發的IM該如何設計“失敗重試”機制？》。
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》一文中關於消息超時與重傳機制的實現思路，也可以參考一下。
8.4 離線消息接收
現代IM是沒有“在線”這個狀態的，不需要給用戶這個信息。但是從技術的層面，用戶掉線了還是要正確的去感知的。
感知方法有幾條：
- a、信令長連接狀態：如果長時間沒收到到服務器的心跳反饋，說明掉線了；
- b、網絡請求失敗次數：如果多次網絡請求失敗，說明”可能“掉線了；
- c、設備網絡狀態檢測：直接檢測網卡狀態就好，一般Android/iOS/Windows/Mac都有相應系統API。
正確檢測到網絡狀態以後，發現網絡從”斷開到恢復“的切換，要去主動拉取離線階段的消息，就可以做到弱網狀態不丟消息（從服務器的離線消息列表拉取）。
上面文字中提到的網絡狀態的確定，涉及到IM裏網絡連接檢查和保活機制問題，是IM裏比較頭疼的問題。
一不小心，又踩進了IM網絡保活這個坑，我就不在這裏展開，有興趣一定要讀讀下面的文章：
《一文讀懂即時通訊應用中的網絡心跳包機制：作用、原理、實現思路等》
8.5 重發消息排序
弱網邏輯的另一個坑是消息排序。
假如有A、B、C 3條消息，A、C發送成功，B發送的時候遇到了網絡閃斷，B觸發自動重試。
那麼接收方的接收順序應該是 A B C還是A C B呢？我觀察過不同的IM產品，處理邏輯各不相同，這個大家有興趣可以去玩一下。
這個解決方法是要依賴上一篇服務架構裏提到的差值排序，同一個人發出的消息，排序按消息附帶的本地時間來排。不同人的消息，按照服務器時間排序。
具體我這邊就不再得復，可以回頭看看本篇中的第四節“4、消息有序性問題”。
8.6 離線指令處理
部分指令操作的時候，網絡可能出現了問題，等網絡恢復以後，要自動同步給服務器。
舉一個例子，大家可以試試手機設置爲飛行模式，然後在微信裏刪除一個聯繫人，看看能不能刪除。然後重新打開網絡，看看這個數據會不會同步到服務器。
類似的邏輯也適用於已讀同步等場景，離線狀態看過的信息，要正確的跟服務器同步。
8.7 小結一下
IM的弱網處理，其實相對還是比較簡單的，基本上自動重試+消息狀態就可以解決絕大部分的問題了。
一些細節處理也並不複雜，主要原因是IM的消息量比較小，網絡恢復後能快速的恢復操作。
視頻會議在弱網下的邏輯，就要複雜的多了。尤其是高丟包的弱網環境下，要盡力去保證音視頻的流暢性。
9、本文小結
《一套億級用戶的IM架構技術乾貨》這期文章的上下兩篇就這麼侃完了，上篇涉及到的IM架構問題倒還好，下篇一不小心又帶出了IM裏的各種熱門問題“坑”，搞IM開發直是一言難盡。。。
建議IM開發的入門朋友們，如果想要系統地學習移動端IM開發的話，應該去讀一讀我整理的那篇IM開發“從入門到放棄”的文章（哈哈哈），就是這篇《新手入門一篇就夠：從零開發移動端IM》。具體我就不再展開了，不然這篇幅又要剎不住車了。。。
10、參考資料
[1] 大規模併發IM服務架構設計
[2] IM的弱網場景優化
[4] IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞
[5] IM開發乾貨分享：如何優雅的實現大量離線消息的可靠投遞
[6] 即時通訊安全篇（二）：探討組合加密算法在IM中的應用
[7] 微信新一代通信安全解決方案：基於TLS1.3的MMTLS詳解
附錄：更多IM開發文章彙總
《IM開發乾貨分享：有贊移動端IM的組件化SDK架構設計實踐》
《IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料彙總》
本文已同步發佈於“即時通訊技術圈”公衆號。
▲ 本文在公衆號上的鏈接是：點此進入。同步發佈鏈接是：http://www.52im.net/thread-3445-1-1.html
