阿里技術分享：電商IM消息平臺，在羣聊、直播場景下的技術實踐
本文由淘寶消息業務團隊李歷岷（花名骨來）原創分享，首次發表於公衆號「淘系技術」，有修訂和改動。php
一、引言
本文來自淘寶消息業務團隊的技術實踐分享，分析了電商IM消息平臺在非傳統IM應用場景下的高發並、強互動羣聊和直播業務中的技術特色，總結並分享了在這些場景下實現大量多對多實時消息分發投遞的一些架構方面的設計實踐。html
目前，阿里的IM消息業務團隊負責新零售領域 IM 消息平臺的建設，經過 IM即時通信產品（push、聊天機器人、單聊、羣聊、消息號和聊天室）構建鏈接消費者和商家的溝通和觸達渠道，天天處理百億級的消費規模，支撐了直播互動、客服服務、商家羣運營、品牌資訊、營銷推送等電商領域 BC 互通的業務場景。算法
（本文同步發佈於：http://www.52im.net/thread-3252-1-1.html）數據庫
二、技術背景
2020年雙11，第一次改變節奏，從光棍節變成雙節棍，從一個峯變成了兩個峯，在新的挑戰下，如何作好技術保障，作好技術支撐，全部技術人都進入了一個新的學習過程。後端
新的形勢下，顯著特色是時間跨度長、活動週期長以及用戶互動玩法更多。從單用戶CC分享到羣內分享，以及直播間互動消息等，做爲電商的IM消息平臺，承接着整個互動的場地。緩存
用戶在整個「互動消息」場景下，能夠進行實時分享、聊天、客服溝通、商家優惠、商家優惠活動和紅包以及商品秒殺等。安全
「消息」做爲用戶和用戶之間架起「鏈接」的重要橋樑，消息鏈接了用戶和用戶、用戶和商家、用戶和平臺等。服務器
如何作到高併發強互動下消息有序地呈如今用戶面前，是消息團隊亙古不變的主題，尤爲是在用戶的互動行爲不肯定性狀況下，在面對不肯定性的流量和規模時，系統應該怎樣作到「絲般順滑」的體驗呢？本文將帶着讀者一塊兒來進行深刻探討。微信
三、強互動消息場景的技術挑戰
不一樣於傳統社區IM消息平臺，電商IM消息平臺有自已的互動場景特色。網絡
3.1 直播間
淘寶直播帶來新的流量變化，百萬在線已經成爲常態化，大量的直播間7X24小時直播帶貨，用戶在直播頻道頁頻繁地進出不一樣的直播間。
有時候被某個直播間吸引，停在那裏等着優惠、紅包和寶貝，隨着主播在直播間喊一嗓子，推送一張寶貝卡片，幾十萬人蜂擁而至秒殺。這樣的場景天天都在上演 ...
3.2 互動PK羣
主互動玩法「超級星秀貓瓜分20億紅包」開啓的時候，意味着大量互動拉贊、分享到好友、分享到羣成爲流量的入口，不管淘口令/圖片等。
大量的消息卡片被轉發、二次轉發帶來的分享裂變效應，天天09:00和晚上22:00成爲活躍的峯值，每一個組隊的用戶拉羣互贊，這樣的場景從10月20日到11月11日持續天天固定時段上演 ...
3.3 不肯定性流量
分享面板入口一次列表排布改變，營銷活動的一次優惠推送，直播頻道頁一次運營活動均可能致使直播間/羣的流量瞬間波動。
紛涌而至的用戶帶來了大量的互動行爲，各類點擊/分享/消息發送紛至沓來。
如何應對這樣的流量和規模，做爲平臺系統，必須可以作到應對不肯定性流量能力和機制，必須從流量入口到流量出口端到端考慮總體的全鏈路架構，是否存在單點瓶頸和缺口。
尤爲在大促前期，系統架構梳理、強弱依賴梳理、上下游鏈路串聯、破壞性壓測、脈衝流量壓測和全鏈路壓測保障和優化，以及配合相關的流量控制、預案保護、業務流量隔離機制、資源調控等手段，才得以作到「不肯定性流量」向「肯定性流量」轉變，才能夠更大程度上保障系統高可用和極致用戶體驗。
四、強互動羣聊中的消息架構實踐
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.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原理。
六、「羣聊」和「直播互動」的消息架構差別思考
由於早期兩套系統各自演進應對不一樣的流量和產品需求，用戶規模化和產品要求帶來的差別化架構。
對比「羣聊」和「直播間互動」兩類互動場景，羣聊基於消息、會話、會話視圖以及附加消息存儲和消息漫遊能力進行總體設計。而對於直播間來講，圍繞直播間大規模實時互動進行抽象設計，充分實現buffer/批量/訂閱關係切片等機制。
對於關係來講：羣關係是強關係，須要用戶確認加羣，才能夠進羣、退羣、查看羣好友等。對於直播間來講是弱關係，用戶進直播、退出直播都是自動完成關係創建和取消，固然用戶能夠後續進入回放直播間。
所以：在功能上和模型設計上須要進一步思考，尤爲現有回放直播間須要一套錄製/回放指令機制，保存互動指令等關鍵性指令數據，而這點在消息IM場景徹底支持了，包括用戶能夠漫遊歷史消息等。
技術的發展不會一塵不變，針對合適的場景進行差別化架構和設計纔是最重要的，一樣在應對不肯定性流量這個場景下，解決問題的方式是不徹底相同的，這個過程須要反覆迭代和優化，圍繞端到端用戶體驗這個核心目標進行技術演進纔是最重要的價值選擇和方向判斷。
七、不肯定性流量的消息QoS思考
不肯定性的流量如何轉爲肯定性流量，是技術必需要解決的「肯定性」問題。
尤爲面對流量須要肯定性進行分解，分優先級保障不一樣的消息QoS能力是「高可用架構」永恆不變的主題，就像應用系統的限流，須要分場景進行流控同樣。
基於這樣的思考推演，QoS分級機制來承諾消息服務SLA，最終才能夠作到隔離/優先級/差別化處理，完成總體的消息順滑體驗。
八、寫在最後
面對不肯定性的流量，須要進行流量再細分以及面向不一樣的場景採起不一樣的處理方案去應對，慣用的手段是指令合併處理、鏈路隔離和共享、租戶存儲隔離、流量打標機制區分場景來源等，以及有相對肯定性的流量大腦進行觀測，在峯值流量來臨以前，須要具有流量感知和預警機制，作好流量的優先級劃分，應急預案是快速失敗限流仍是慢速等待消費以及優先級控制等機制。
同時在系統層面，須要作到水平擴展能力，也就是可否經過彈性擴容的方式應對高流量的峯值，另外須要作到總體全鏈路合理的架構設計，避免「寫入放大」以及「讀取放大」的單點問題產生，須要針對入口流量和出口流量進行比對，是否能夠作到上下游1:1的狀況下，儘量地避免單點瓶頸帶來集羣瓶頸乃至總體不可用。
「高可用架構「是技術人員永恆不變的主題之一，隨着用戶規模增加以及集中流量爆發的情形下，更須要敏銳地找到全鏈路單點問題，提早預斷定義出面臨的問題。而後給出合理的優化方案，最終灰度切流以及全鏈路壓測驗證保證總體方案有序推動，尤爲面對的在線系統優化，比如開着飛機換輪胎同樣。具有優化效果數據和監控是衡量每一步的預期收益，只有這樣才能夠作好「架構演進」，才能夠持續交付更好的用戶產品體驗，贏得用戶的喜好，以及互動效果和產品流暢性才能夠獲得用戶滿意度提高。架構演進是個動態化的過程，須要持續投入和改進，推進全鏈路總體落地。
附錄：更多相關資料
[1] 有關阿里巴巴的文章分享：
《阿里釘釘技術分享：企業級IM王者——釘釘在後端架構上的過人之處》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《釘釘——基於IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》
《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》
《重磅發佈：《阿里巴巴Android開發手冊(規約)》[附件下載]》
《阿里技術分享：電商IM消息平臺，在羣聊、直播場景下的技術實踐》
[2] 有關IM架構設計的文章：
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐》
《阿里技術分享：阿里自研金融級數據庫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
- 1. 阿里技術分享：電商IM消息平臺，在羣聊、直播場景下的技術實踐
- 2. 優酷智能檔在大型直播場景下的技術實踐
- 3. 阿里技術面分享
- 4. IM開發乾貨分享：網易雲信IM客戶端的聊天消息全文檢索技術實踐
- 5. 直播開篇——直播場景和技術分析
- 6. 實時音頻混音技術在視頻直播場景中的實踐
- 7. 網易雲信技術分享：IM中的萬人羣聊技術方案實踐總結
- 8. 直播平臺搭建開發技術分享
- 9. （一）海哇VR全景電商平臺-技術架構分析
- 10. 【技術分享】攜程實時數據平臺的實踐
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • Hibernate的快照技術 - Hibernate教程
- • Docker容器實戰(一) - 封神Server端技術
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）