本文由淘寶消息業務團隊李歷岷（花名骨來）原創分享，首次發表于公眾號“淘系技術”，有修訂和改動。
1、引言
本文來自淘寶消息業務團隊的技術實踐分享，分析了電商IM消息平臺在非傳統IM應用場景下的高發并、強互動群聊和直播業務中的技術特點，總結并分享了在這些場景下實現大量多對多實時消息分發投遞的一些架構方面的設計實踐。
目前，阿里的IM消息業務團隊負責新零售領域 IM 消息平臺的建設，通過 IM即時通訊產品（push、聊天機器人、單聊、群聊、消息號和聊天室）構建連接消費者和商家的溝通和觸達渠道，每天處理百億級的消費規模，支撐了直播互動、客服服務、商家群運營、品牌資訊、營銷推送等電商領域 BC 互通的業務場景。
（本文同步發布于：http://www.52im.net/thread-3252-1-1.html）
2、技術背景
2020年雙11，第一次改變節奏，從光棍節變成雙節棍，從一個峰變成了兩個峰，在新的挑戰下，如何做好技術保障，做好技術支撐，所有技術人都進入了一個新的學習過程。
新的形勢下，顯著特點是時間跨度長、活動周期長以及用戶互動玩法更多。從單用戶CC分享到群內分享，以及直播間互動消息等，作為電商的IM消息平臺，承接著整個互動的場地。
用戶在整個“互動消息”場景下，可以進行實時分享、聊天、客服溝通、商家優惠、商家優惠活動和紅包以及商品秒殺等。
“消息”作為用戶和用戶之間架起“連接”的重要橋梁，消息連接了用戶和用戶、用戶和商家、用戶和平臺等。
如何做到高并發強互動下消息有序地呈現在用戶面前，是消息團隊亙古不變的主題，尤其是在用戶的互動行為不確定性情況下，在面對不確定性的流量和規模時，系統應該怎樣做到“絲般順滑”的體驗呢？本文將帶著讀者一起來進行深入探討。
3、強互動消息場景的技術挑戰
不同于傳統社區IM消息平臺，電商IM消息平臺有自已的互動場景特點。
3.1 直播間
淘寶直播帶來新的流量變化，百萬在線已經成為常態化，大量的直播間7X24小時直播帶貨，用戶在直播頻道頁頻繁地進出不同的直播間。
有時候被某個直播間吸引，停在那里等著優惠、紅包和寶貝，隨著主播在直播間喊一嗓子，推送一張寶貝卡片，幾十萬人蜂擁而至秒殺。這樣的場景每天都在上演 ...
3.2 互動PK群
主互動玩法“超級星秀貓瓜分20億紅包”開啟的時候，意味著大量互動拉贊、分享到好友、分享到群成為流量的入口，無論淘口令/圖片等。
大量的消息卡片被轉發、二次轉發帶來的分享裂變效應，每天09:00和晚上22:00成為活躍的峰值，每個組隊的用戶拉群互贊，這樣的場景從10月20日到11月11日持續每天固定時段上演 ...
3.3 不確定性流量
分享面板入口一次列表排布改變，營銷活動的一次優惠推送，直播頻道頁一次運營活動都可能導致直播間/群的流量瞬間波動。
紛涌而至的用戶帶來了大量的互動行為，各種點擊/分享/消息發送紛至沓來。
如何應對這樣的流量和規模，作為平臺系統，必須能夠做到應對不確定性流量能力和機制，必須從流量入口到流量出口端到端考慮整體的全鏈路架構，是否存在單點瓶頸和缺口。
尤其在大促前期，系統架構梳理、強弱依賴梳理、上下游鏈路串聯、破壞性壓測、脈沖流量壓測和全鏈路壓測保障和優化，以及配合相關的流量控制、預案保護、業務流量隔離機制、資源調控等手段，才得以做到“不確定性流量”向“確定性流量”轉變，才可以更大程度上保障系統高可用和極致用戶體驗。
4、強互動群聊中的消息架構實踐
4.1 傳統IM中“寫擴散”架構的瓶頸
隨著2018年淘系電商首推“雙11合伙人計劃”，更簡單直接的雙11玩法，給大眾帶來更多期待和驚喜。
尤其是蓋樓互贊活動更是把“群聊”推上風口浪尖, 在手淘APP內部分享比在微信和釘釘等社交/企業軟件分享更加便捷和高效，用戶不停地在群內互動分享拉贊、通過好友助力提升蓋樓積分。
基于傳統的IM架構技術，尤其在群內聊天或者分享，每條消息按照群內人數進行寫擴散，按照主互動500人群規模來計算，平均群大小320+，1:N的寫入必然導致寫入DB的RT以及存儲壓力，按照DB庫承接120w/s寫入速度，導致消息上行3K/s的極限，而實際參與互動分享的用戶在峰值的時候遠大于這部分互動分享和聊天消息流量。
其次集群的寫入不可能完全給IM聊天消息，還有其它的營銷活動、交易、物流等通知類型的消息。
基于傳統IM的“寫擴散”架構，在高并發、強互動場景下遇到了瓶頸，導致消息大量的延遲下推，影響最終用戶體驗。
4.2 “讀擴散”架構的應用
基于寫擴散架構的消息擴散比是1:N，那能否做到消息擴散比是1:1呢？
答案是肯定的：針對群內的消息可以分為“非個性化消息”和“個性化消息”，所謂“非個性化消息”就是大家看到都是一樣的，應該只需要寫一條數據，群內成員可以共享取這條數據（所謂“個性化消息”，指定某個成員發送的單邊消息，譬如進群歡迎語等）。
在群內，99.99%都是“非個性化消息”，也就是可以從1:N壓縮到1:1寫入。
基于這個理論假設，需要考慮“讀擴散”讓每個用戶的消息從對應的“群會話消息隊列同步“數據，而不是從”用戶隊列同步“數據。
其中同步隊列圍繞隊列offset偏移量進行，通過隊列的自增syncId保證有序，每個客戶端維護相應的隊列的同步位點，采取“客戶端存儲位點的去中心化“方案，實現”下行消息的推拉“結合。
通過隊列位點syncId進行比對，如果服務端消息隊列syncId-客戶端隊列syncId=1，表示云端消息無空洞，否則攜帶客戶端的隊列和對應的syncId到云端重新同步區間數據，實現最終一致性。
傳統的IM產品：騰訊QQ、騰訊微信、網易云通訊、抖音IM、釘釘IM、脈脈IM、支付寶IM。
PS：市面上APP80%都具備IM聊天能力，均采取寫擴散簡單模式進行云端消息同步。
4.3 “讀擴散”、“寫擴散”技術方案對比
4.3.1）寫擴散技術：
優點：
- 1）整體架構簡潔，方案簡單，維護用戶同步隊列實現數據同步機制；
- 2）無論是單聊還是群聊等會話消息，寫入用戶維度同步隊列，集中獲取同步數據；
- 3）推和拉情況下，存儲模型和數據處理簡單，且天然支持個性化數據。
缺點：
- 1）群會話消息，天然存在1:N寫入擴散比，存儲壓力N倍壓力，在線用戶收到消息延遲增大；
- 2）多個群內消息隊列混合在同步隊列，無優先級處理能力，無法針對互動群等做隔離。
4.3.2）讀擴散技術：
優點：
- 1）降低寫擴散N倍的DB存儲壓力，減少下行在線用戶端到端擴散的RT時間；
- 2）提升消息上行集群整體的吞吐量，用戶體驗更流暢；
- 3）端到端實現會話級別的同步優先級隊列，實現差異化服務。
缺點：
- 1）整體架構偏復雜，需要維護每個動態會話消息同步隊列，端側需要實時感知新增的動態同步隊列；
- 2）客戶端冷啟動需要分散讀取多個會話消息同步隊列數據，對于存儲會帶來讀QPS壓力。
4.4 讀寫擴散混合模式
核心在于架構的演進推進“讀寫擴散混合模式“落地，結合兩者的優點進行云端一體化數據同步技術，覆蓋幾千萬互動群用戶，保證整體峰值上行消息以及用戶在群內端到端延遲體驗，做到一條上行消息500ms以內到達群內其他用戶端側，讓整體用戶體驗提升明顯，群內強互動成為可能。
5、電商直播互動中的消息架構實踐
5.1 技術挑戰
電商直播呈現大直播若干個（大于30W同時在線）、中直播間幾百個、小直播幾萬個這樣分布，尤其是晚會和主播帶來的熱點直播間效應，對系統整體的IM消息架構存在熱點帶來嚴重挑戰。
熱點問題的產生需要從不確定性的流量來源說起。
直播間人員規模天然和群聊不一樣（單個群<=500人），一個直播間可以突破40萬-200萬之間設備同時在線。
直播間在另一個層面是“特殊的群”，群維護了群和群成員強關系，直播間維護直播和設備之間的訂閱弱關系，在擴散維度群按照500人進行分庫分表切片模式分發下行消息，直播間需要以直播間幾十萬設備作為分段切片進行分發。同時直播間的指令消息如果不加以干預，會形成超大的流量熱點和擴散問題。那么針對這個問題如何應對？
直播間互動全鏈路和核心處理節點簡易時序圖如下：
即：觀眾互動消息 -> 網關接入 -> 應用系統Buffer(秒級直播間維度消息) -> 編碼、合并、批量消息流 -> 直播間維度設備擴散 -> 設備長連通道推送 -> 設備接收 -> 解碼消息 -> 業務處理。
5.2 應對手段
5.2.1）充分利用直播間在線人數：
針對大直播間和小直播間區分對待，充分利用在線人數這個關鍵性指標。
譬如小直播間不做buffer隊列處理（所謂buffer，就是維護topic維度的緩沖隊列），支持N秒或消息條數的異步flush機制，實現削峰過程。
其中針對“可靠消息”進行持久化緩存存儲，如果當前消息推送失敗，重試3次或者下一條消息再次攜帶失敗的可靠消息，整體按照推拉結合的方式，端側做重復消息去重控制。
5.2.2）用戶進出房間關系維護：
從用戶第一次進直播間，發起訂閱請求，最終通過大小直播間分片進行路由到指定的直播間，針對特殊大直播間提前做好集群分片。
或者通過每天的離線數據分析大直播間的賬號，主播開播創建直播間的時候，提前做好分片確定性，在脈沖綁定關系的時候，流量分散到N臺訂閱集群進行綁定關系建立。
5.2.3）流控策略考慮：
流控不等于一刀切，而是針對不同的subType指令進行控制。
針對可靠消息（紅包、優惠、寶貝卡片）等進行持久化存儲，利用多次消息下推攜帶機制，同時兼顧端側拉取機制，保證消息最終一致性且在3秒以內到達端側。
5.2.4）一致性hash問題-熱點直播間：
一致性Hash的架構必然存在熱點問題，如果在直播間進行分散架構，必然存在指令風暴問題?；诖?，需要進行Hash熱點二次打散處理。
針對這樣的熱點問題技術上是可行的，熱點問題散列到多臺IP機器上進行流量承接，另外需要考慮直播間維度的統計數據分布式合并等問題，需要用到分布式鎖并發寫入統計數據，且直播維度數據合并計算，類似JDKStriped64原理。
6、“群聊”和“直播互動”的消息架構差異思考
因為早期兩套系統各自演進應對不同的流量和產品需求，用戶規?；彤a品要求帶來的差異化架構。
對比“群聊”和“直播間互動”兩類互動場景，群聊基于消息、會話、會話視圖以及附加消息存儲和消息漫游能力進行整體設計。而對于直播間來說，圍繞直播間大規模實時互動進行抽象設計，充分實現buffer/批量/訂閱關系切片等機制。
對于關系來說：群關系是強關系，需要用戶確認加群，才可以進群、退群、查看群好友等。對于直播間來說是弱關系，用戶進直播、退出直播都是自動完成關系建立和取消，當然用戶可以后續進入回放直播間。
因此：在功能上和模型設計上需要進一步思考，尤其現有回放直播間需要一套錄制/回放指令機制，保存互動指令等關鍵性指令數據，而這點在消息IM場景完全支持了，包括用戶可以漫游歷史消息等。
技術的發展不會一塵不變，針對合適的場景進行差異化架構和設計才是最重要的，同樣在應對不確定性流量這個場景下，解決問題的方式是不完全相同的，這個過程需要反復迭代和優化，圍繞端到端用戶體驗這個核心目標進行技術演進才是最重要的價值選擇和方向判斷。
7、不確定性流量的消息QoS思考
不確定性的流量如何轉為確定性流量，是技術必須要解決的“確定性”問題。
尤其面對流量需要確定性進行分解，分優先級保障不同的消息QoS能力是“高可用架構”永恒不變的主題，就像應用系統的限流，需要分場景進行流控一樣。
基于這樣的思考推演，QoS分級機制來承諾消息服務SLA，最終才可以做到隔離/優先級/差異化處理，完成整體的消息順滑體驗。
8、寫在最后
面對不確定性的流量，需要進行流量再細分以及面向不同的場景采取不同的處理方案去應對，慣用的手段是指令合并處理、鏈路隔離和共享、租戶存儲隔離、流量打標機制區分場景來源等，以及有相對確定性的流量大腦進行觀測，在峰值流量來臨之前，需要具備流量感知和預警機制，做好流量的優先級劃分，應急預案是快速失敗限流還是慢速等待消費以及優先級控制等機制。
同時在系統層面，需要做到水平擴展能力，也就是能否通過彈性擴容的方式應對高流量的峰值，另外需要做到整體全鏈路合理的架構設計，避免“寫入放大”以及“讀取放大”的單點問題產生，需要針對入口流量和出口流量進行比對，是否可以做到上下游1:1的情況下，盡可能地避免單點瓶頸帶來集群瓶頸乃至整體不可用。
“高可用架構“是技術人員永恒不變的主題之一，隨著用戶規模增長以及集中流量爆發的情形下，更需要敏銳地找到全鏈路單點問題，提前預判定義出面臨的問題。然后給出合理的優化方案，最終灰度切流以及全鏈路壓測驗證保證整體方案有序推進，尤其面對的在線系統優化，好比開著飛機換輪胎一樣。具備優化效果數據和監控是衡量每一步的預期收益，只有這樣才可以做好“架構演進”，才可以持續交付更好的用戶產品體驗，贏得用戶的喜愛，以及互動效果和產品流暢性才可以得到用戶滿意度提升。架構演進是個動態化的過程，需要持續投入和改進，推動全鏈路整體落地。
附錄：更多相關資料
[1] 有關阿里巴巴的文章分享：
《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》
《現代IM系統中聊天消息的同步和存儲方案探討》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》
《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》
《重磅發布：《阿里巴巴Android開發手冊(規約)》[附件下載]》
《作者談《阿里巴巴Java開發手冊(規約)》背后的故事》
《《阿里巴巴Android開發手冊(規約)》背后的故事》
《干了這碗雞湯：從理發店小弟到阿里P10技術大牛》
《揭秘阿里、騰訊、華為、百度的職級和薪酬體系》
《淘寶技術分享：手淘億級移動端接入層網關的技術演進之路》
《難得干貨，揭秘支付寶的2維碼掃碼技術優化實踐之路》
《淘寶直播技術干貨：高清、低延時的實時視頻直播技術解密》
《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》
[2] 有關IM架構設計的文章：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通信協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分布式即時通訊(IM)系統理論架構方案》
《從零到卓越：京東客服即時通訊系統的技術架構演進歷程》
《蘑菇街即時通訊/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《王者榮耀2億用戶量的背后：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《以微博類應用場景為例，總結海量社交系統的架構設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分布式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背后的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高并發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高并發技術實踐》
《社交軟件紅包技術解密(八)：全面解密微博紅包技術方案》
《社交軟件紅包技術解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構等》
《社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐》
《社交軟件紅包技術解密(十一)：解密微信紅包隨機算法(含代碼實現)》
《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現IM的負載均衡？》
《即時通訊新手入門：快速理解RPC技術——基本概念、原理和用途》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔心我的技術選型了》
《從游擊隊到正規軍(一)：馬蜂窩旅游網的IM系統架構演進之路》
《從游擊隊到正規軍(二)：馬蜂窩旅游網的IM客戶端架構演進和實踐總結》
《從游擊隊到正規軍(三)：基于Go的馬蜂窩旅游網分布式IM系統技術實踐》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《瓜子IM智能客服系統的數據架構設計（整理自現場演講，有配套PPT）》
《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》
《微信后臺基于時間序的新一代海量數據存儲架構的設計實踐》
《IM開發基礎知識補課(九)：想開發IM集群？先搞懂什么是RPC！》
《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》
>> 更多同類文章 ……
本文已同步發布于“即時通訊技術圈”公眾號：
▲ 本文在公眾號上的鏈接是：點此進入，原文鏈接是：http://www.52im.net/thread-3252-1-1.html