2020年雙11，第一次改變節奏，從光棍節變成雙節棍，從一個峰變成了兩個峰，在新的挑戰下，如何做好技術保障，做好技術支撐，所有技術人都進入了一個新的學習過程。

新的形勢下，顯著特點是時間跨度長、活動周期長以及用戶互動玩法更多。從單用戶CC分享到群內分享，以及直播間互動消息等，作為電商的消息IM承接著整個互動的場地，用戶在整個“互動消息”場景下，可以進行實時分享、聊天、客服溝通、商家優惠、商家優惠活動和紅包以及商品秒殺等。“消息”作為用戶和用戶之間架起“連接”的重要橋梁，消息連接了用戶和用戶、用戶和商家、用戶和平臺等。

如何做到高并發強互動下消息有序地呈現在用戶面前，是消息團隊亙古不變的主題，尤其是在用戶的互動行為不確定性情況下，在面對不確定性的流量和規模時，系統應該怎樣做到“絲般順滑”的體驗呢？本文將帶著讀者一起來進行深入探討。

推薦閱讀：讀者對傳統的IM系統架構有所了解

互動場景挑戰

---

直播間：淘寶直播帶來新的流量變化，百萬在線已經成為常態化，大量的直播間7X24小時直播帶貨，用戶在直播頻道頁頻繁地進出不同的直播間，有時候被某個直播間吸引，停在那里等著優惠、紅包和寶貝，隨著主播在直播間喊一嗓子，推送一張寶貝卡片，幾十萬人蜂擁而至秒殺。這樣的場景每天都在上演...

互動PK群:主互動玩法“超級星秀貓瓜分20億紅包”開啟的時候，意味著大量互動拉贊、分享到好友、分享到群成為流量的入口，無論淘口令/圖片等，大量的消息卡片被轉發、二次轉發帶來的分享裂變效應，每天09:00和晚上22:00成為活躍的峰值，每個組隊的用戶拉群互贊，這樣的場景從10月20日到11月11日持續每天固定時段上演...

不確定性流量：分享面板入口一次列表排布改變，營銷活動的一次優惠推送，直播頻道頁一次運營活動都可能導致直播間/群的流量瞬間波動，紛涌而至的用戶帶來了大量的互動行為，各種點擊/分享/消息發送紛至沓來，如何應對這樣的流量和規模，作為平臺系統，必須能夠做到應對不確定性流量能力和機制，必須從流量入口到流量出口端到端考慮整體的全鏈路架構，是否存在單點瓶頸和缺口，尤其在大促前期，系統架構梳理、強弱依賴梳理、上下游鏈路串聯、破壞性壓測、脈沖流量壓測和全鏈路壓測保障和優化，以及配合相關的流量控制、預案保護、業務流量隔離機制、資源調控等手段，才得以做到“不確定性流量”向“確定性流量”轉變，才可以更大程度上保障系統高可用和極致用戶體驗。

???問題定義之群聊

隨著2018年淘系電商首推“雙11合伙人計劃”，更簡單直接的雙11玩法，給大眾帶來更多期待和驚喜。尤其是蓋樓互贊活動更是把“群聊”推上風口浪尖, 在手淘APP內部分享比在微信和釘釘等社交/企業軟件分享更加便捷和高效, 用戶不停地在群內互動分享拉贊,通過好友助力提升蓋樓積分。

基于傳統的IM架構技術，尤其在群內聊天或者分享，每條消息按照群內人數進行寫擴散，按照主互動500人群規模來計算，平均群大小320+，1:N的寫入必然導致寫入DB的RT以及存儲壓力，按照DB庫承接120w/s寫入速度，導致消息上行3K/s的極限，而實際參與互動分享的用戶在峰值的時候遠大于這部分互動分享和聊天消息流量，其次集群的寫入不可能完全給IM聊天消息，還有其它的營銷活動、交易、物流等通知類型的消息。基于“寫擴散”架構，在高并發互動場景下遇到了瓶頸，導致消息大量的延遲下推，影響最終用戶體驗。

基于寫擴散的擴散比1:N，能否做到1:1寫入？答案是肯定，針對群內的消息可以分為“非個性化消息”和“個性化消息”，所謂“非個性化消息”就是大家看到都是一樣的，應該只需要寫一條數據，群內成員可以共享取這條數據，所謂“個性化消息”，指定某個成員發送的單邊消息，譬如進群歡迎語等。

在群內，99.99%都是“非個性化消息”，也就是可以從1:N壓縮到1:1寫入，基于這個理論假設，需要考慮“讀擴散”讓每個用戶的消息從對應的“群會話消息隊列同步“數據，而不是從”用戶隊列同步“數據，其中同步隊列圍繞隊列offset偏移量進行，通過隊列的自增syncId保證有序，每個客戶端維護相應的隊列的同步位點，采取“客戶端存儲位點的去中心化“方案，實現”下行消息的推拉“結合，通過隊列位點syncId進行比對，如果服務端消息隊列syncId-客戶端隊列syncId=1，表示云端消息無空洞，否則攜帶客戶端的隊列和對應的syncId到云端重新同步區間數據，實現最終一致性。

業界IM：騰訊QQ、騰訊微信、網易云通訊、抖音IM、釘釘IM、脈脈IM、支付寶IM

備注：市面上APP80%都具備IM聊天能力，均采取寫擴散簡單模式進行云端消息同步

讀寫擴散技術方案對比

1、寫擴散技術

優點：

• 整體架構簡潔，方案簡單，維護用戶同步隊列實現數據同步機制

• 無論是單聊還是群聊等會話消息，寫入用戶維度同步隊列，集中獲取同步數據

• 推和拉情況下，存儲模型和數據處理簡單，且天然支持個性化數據

缺點：

• 群會話消息，天然存在1:N寫入擴散比，存儲壓力N倍壓力，在線用戶收到消息延遲增大

• 多個群內消息隊列混合在同步隊列，無優先級處理能力，無法針對互動群等做隔離

2、讀擴散技術

優點：

• 降低寫擴散N倍的DB存儲壓力，減少下行在線用戶端到端擴散的RT時間

• 提升消息上行集群整體的吞吐量，用戶體驗更流暢

• 端到端實現會話級別的同步優先級隊列，實現差異化服務

缺點：

• 整體架構偏復雜，需要維護每個動態會話消息同步隊列，端側需要實時感知新增的動態同步隊列

• 客戶端冷啟動需要分散讀取多個會話消息同步隊列數據，對于存儲會帶來讀QPS壓力

3、讀寫擴散混合模式

核心在于架構的演進推進“讀寫擴散混合模式“落地，結合兩者的優點進行云端一體化數據同步技術，覆蓋幾千萬互動群用戶，保證整體峰值上行消息以及用戶在群內端到端延遲體驗，做到一條上行消息500ms以內到達群內其他用戶端側，讓整體用戶體驗提升明顯，群內強互動成為可能。

???問題定義之直播互動消息

電商直播呈現大直播若干個(大于30W同時在線）、中直播間幾百個、小直播幾萬個這樣分布，尤其是晚會和主播帶來的熱點直播間效應，對系統整體的架構存在熱點帶來嚴重挑戰。

熱點問題的產生需要從不確定性的流量來源說起。直播間人員規模天然和群聊不一樣(單個群<=500人），一個直播間可以突破40萬-200萬之間設備同時在線，直播間在另一個層面是“特殊的群”，群維護了群和群成員強關系，直播間維護直播和設備之間的訂閱弱關系，在擴散維度群按照500人進行分庫分表切片模式分發下行消息，直播間需要以直播間幾十萬設備作為分段切片進行分發。同時直播間的指令消息如果不加以干預，會形成超大的流量熱點和擴散問題，那么針對這個問題如何應對？

直播間互動全鏈路和核心處理節點

簡易時序圖如下：觀眾互動消息->網關接入->應用系統Buffer(秒級直播間維度消息)-> 編碼、合并、批量消息流->直播間維度設備擴散->設備長連通道推送->設備接收->解碼消息->業務處理

充分利用直播間在線人數

針對大直播間和小直播間區分對待，充分利用在線人數這個關鍵性指標，譬如小直播間不做buffer隊列處理，所謂buffer，就是維護topic維度的緩沖隊列，支持N秒或消息條數的異步flush機制，實現削峰過程，其中針對“可靠消息”進行持久化緩存存儲，如果當前消息推送失敗，重試3次或者下一條消息再次攜帶失敗的可靠消息，整體按照推拉結合的方式，端側做重復消息去重控制。

用戶進出房間關系維護

從用戶第一次進直播間，發起訂閱請求，最終通過大小直播間分片進行路由到指定的直播間，針對特殊大直播間提前做好集群分片，或者通過每天的離線數據分析大直播間的賬號，主播開播創建直播間的時候，提前做好分片確定性，在脈沖綁定關系的時候，流量分散到N臺訂閱集群進行綁定關系建立。

流控策略考慮

流控不等于一刀切，而是針對不同的subType指令進行控制，針對可靠消息（紅包、優惠、寶貝卡片）等進行持久化存儲，利用多次消息下推攜帶機制，同時兼顧端側拉取機制，保證消息最終一致性且在3秒以內到達端側。

一致性hash問題-熱點直播間

一致性Hash的架構必然存在熱點問題，如果在直播間進行分散架構，必然存在指令風暴問題，基于此需要進行Hash熱點二次打散處理，針對這樣的熱點問題技術上是可行的，熱點問題散列到多臺IP機器上進行流量承接，另外需要考慮直播間維度的統計數據分布式合并等問題，需要用到分布式鎖并發寫入統計數據，且直播維度數據合并計算，類似JDKStriped64原理。

對比兩套架構思考

---

???規模差異化架構思考

因為早期兩套系統各自演進應對不同的流量和產品需求，用戶規模化和產品要求帶來的差異化架構，對比“群聊”和“直播間互動”兩類互動場景，群聊基于消息、會話、會話視圖以及附加消息存儲和消息漫游能力進行整體設計，而對于直播間來說，圍繞直播間大規模實時互動進行抽象設計，充分實現buffer/批量/訂閱關系切片等機制。

對于關系來說，群關系是強關系，需要用戶確認加群，才可以進群、退群、查看群好友等；對于直播間來說是弱關系，用戶進直播、退出直播都是自動完成關系建立和取消，當然用戶可以后續進入回放直播間。

因此，在功能上和模型設計上需要進一步思考，尤其現有回放直播間需要一套錄制/回放指令機制，保存互動指令等關鍵性指令數據，而這點在消息IM場景完全支持了，包括用戶可以漫游歷史消息等。

技術的發展不會一塵不變，針對合適的場景進行差異化架構和設計才是最重要的，同樣在應對不確定性流量這個場景下，解決問題的方式是不完全相同的，這個過程需要反復迭代和優化，圍繞端到端用戶體驗這個核心目標進行技術演進才是最重要的價值選擇和方向判斷。

???不確定性流量的QoS思考

不確定性的流量如何轉為確定性流量，是技術必須要解決的“確定性”問題。尤其面對流量需要確定性進行分解，分優先級保障不同的消息QoS能力是“高可用架構永恒不變”的主題，就像應用系統的限流，需要分場景進行流控一樣。基于這樣的思考推演，QoS分級機制來承諾消息服務SLA，最終才可以做到隔離/優先級/差異化處理，完成整體的消息順滑體驗。

小結

---

面對不確定性的流量，需要進行流量再細分以及面向不同的場景采取不同的處理方案去應對，慣用的手段是指令合并處理、鏈路隔離和共享、租戶存儲隔離、流量打標機制區分場景來源等，以及有相對確定性的流量大腦進行觀測，在峰值流量來臨之前，需要具備流量感知和預警機制，做好流量的優先級劃分，應急預案是快速失敗限流還是慢速等待消費以及優先級控制等機制。

同時在系統層面，需要做到水平擴展能力，也就是能否通過彈性擴容的方式應對高流量的峰值，另外需要做到整體全鏈路合理的架構設計，避免“寫入放大”以及“讀取放大”的單點問題產生，需要針對入口流量和出口流量進行比對，是否可以做到上下游1:1的情況下，盡可能地避免單點瓶頸帶來集群瓶頸乃至整體不可用。

“高可用架構“是技術人員永恒不變的主題之一，隨著用戶規模增長以及集中流量爆發的情形下，更需要敏銳地找到全鏈路單點問題，提前預判定義出面臨的問題，然后給出合理的優化方案，最終灰度切流以及全鏈路壓測驗證保證整體方案有序推進，尤其面對的在線系統優化，好比開著飛機換輪胎一樣。具備優化效果數據和監控是衡量每一步的預期收益，只有這樣才可以做好“架構演進”，才可以持續交付更好的用戶產品體驗，贏得用戶的喜愛，以及互動效果和產品流暢性才可以得到用戶滿意度提升。架構演進是個動態化的過程，需要持續投入和改進，推動全鏈路整體落地。

淘系技術部——消息業務團隊

我們負責阿里新零售領域 IM 消息平臺的建設，通過 IM即時通訊產品（push、聊天機器人、單聊、群聊、消息號和聊天室）構建連接消費者和商家的溝通和觸達渠道，我們每天服務上億消費者和數百萬商家，處理百億級的消費規模，支撐了直播互動、客服服務、商家群運營、品牌資訊、營銷推送等電商領域 BC 互通的業務場景；同時，我們在消費者的購物體驗上不斷探索創新——直播、AR試用、游戲互動，為新的購物玩法提供靈活穩定的基礎設施，實現阿里電商生態重要支點，為上百家APP 提供安全、穩定、標準化的電商組件SDK。不斷提升消費這的體驗和活躍，提升商家服務的效率和能力，促進商家業務增長。

聯系電話：18651806651

郵箱????：limin.llm@alibaba-inc.com

???拓展閱讀

作者|李歷岷(骨來)

編輯|橙子君

出品|阿里巴巴新零售淘系技術

總結

以上是生活随笔為你收集整理的电商互动消息如何进行架构演进？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。