聊聊高並髮長連接架構:百萬在線的美拍直播彈幕系統如何實現

2021-02-15 高可用架構

導讀：直播彈幕是直播系統的核心功能之一。如何迅速作出一個有很好擴展性的彈幕系統？如何應對業務迅速發展？相信很多工程師/架構師都有自己的想法。本文作者是美拍的架構師，經歷了直播彈幕從無到有，從小到大的過程。本文是作者對構建彈幕系統的經驗總結。

王靜波，畢業於西安交通大學，曾任職於網易和新浪微博，微博工作期間負責開放平臺業務和技術體系建設。2015 年 9 月加入美圖，就職於架構平臺部，目前負責部分核心業務和基礎設施的研發工作，包括彈幕服務、Feed 服務、任務調度和質量監控體系等。十餘年的後端研發經歷，擁有豐富的後端研發經驗，對於構建高可用、高並發的系統有較多實踐經驗。歡迎通過 wjb@meitu.com 跟他交流。

直播彈幕指直播間的用戶，禮物，評論，點讚等消息，是直播間交互的重要手段。美拍直播彈幕系統從 2015 年 11 月到現在，經過了三個階段的演進，目前能支撐百萬用戶同時在線。比較好地詮釋了根據項目的發展階段，進行平衡演進的過程。這三個階段分別是快速上線，高可用保障體系建設，長連接演進。

一、快速上線


消息模型


美拍直播彈幕系統在設計初期的核心要求是：快速上線，並能支撐百萬用戶同時在線。基於這兩點，我們策略是前中期 HTTP 輪詢方案，中後期替換為長連接方案。因此在業務團隊進行 HTTP 方案研發的同時，基礎研發團隊也緊鑼密鼓地開發長連接系統。

直播間消息，相對於 IM 的場景，有其幾個特點

對於用戶來說，在直播間有三個典型的操作：

進入直播間，拉取正在觀看直播的用戶列表；

接收直播間持續接收彈幕消息；

自己發消息；

我們把禮物，評論，用戶的數據都當做消息來看待。經過考慮選擇了 Redis 的 sortedset 存儲消息，消息模型如下：

用戶發消息，通過 Zadd，其中 score 消息的相對時間；

接收直播間的消息，通過 ZrangeByScore 操作，兩秒一次輪詢；

進入直播間，獲取用戶的列表，通過 Zrange 操作來完成；

 

因此總的流程是

不過這裡有一個隱藏的並發問題：用戶可能丟消息。

如上圖所示，某個用戶從第6號評論開始拉取，同時有兩個用戶在發表評論，分別是10,11號評論。如果11號評論先寫入，用戶剛好把6,7,8,9,11號拉走，用戶下次再拉取消息，就從12號開始拉取，結果是：用戶沒有看到10號消息。

為了解決這個問題，我們加上了兩個機制:

消息模型及並發問題解決後，開發就比較順暢，系統很快就上線，達到預先預定目標。

上線後暴露問題的解決


上線後，隨著量的逐漸增加，系統陸續暴露出三個比較嚴重的問題，我們一一進行解決

問題一：消息串行寫入 Redis，如果某個直播間消息量很大，那麼消息會堆積在 Kafka 中，消息延遲較大。

解決辦法：

消息寫入流程：前端機-> Kafka -> 處理機 -> Redis

前端機：如果延遲小，則只寫入一個 Kafka 的partion；如果延遲大，則這個直播的這種消息類型寫入 Kafka 的多個partion。

處理機：如果延遲小，加鎖串行寫入 Redis；如果延遲大，則取消鎖。因此有四種組合，四個檔位，分別是

一個partion, 加鎖串行寫入 Redis, 最大並發度:1

多個partition,加鎖串行寫入 Redis, 最大並發度:Kafka partion的個數

一個partion, 不加鎖並行寫入 Redis, 最大並發度: 處理機的線程池個數

多個partion, 不加鎖並行寫入 Redis，最大並發度: Kafka partition個數處理機線程池的個數

延遲程度判斷：前端機寫入消息時，打上消息的統一時間戳，處理機拿到後，延遲時間 = 現在時間 - 時間戳；

檔位選擇:自動選擇檔位，粒度:某個直播間的某個消息類型


問題二：用戶輪詢最新消息，需要進行 Redis 的 ZrangByScore 操作，redis slave 的性能瓶頸較大

解決辦法:

 

解釋：這裡本地緩存與平常使用的本地緩存問題，有一個最大區別：成本問題。

如果所有直播間的消息都進行緩存，假設同時有1000個直播間，每個直播間5種消息類型，本地緩存每隔1秒拉取一次數據，40臺前端機，那麼對 Redis 的訪問QPS是   1000 * 5 * 40 = 20萬。成本太高，因此我們只有大直播間才自動開啟本地緩存，小直播間不開啟。

問題三:彈幕數據也支持回放，直播結束後，這些數據存放於 Redis 中，在回放時，會與直播的數據競爭 Redis 的 cpu 資源。

解決辦法:

直播結束後，數據備份到 mysql；

增加一組回放的 Redis；

前端機增加回放的 local cache；

 

解釋：回放時，讀取數據順序是: local cache -> Redis -> mysql。localcache 與回放 Redis 都可以只存某個直播某種消息類型的部分數據，有效控制容量；local cache與回放 Redis 使用SortedSet數據結構，這樣整個系統的數據結構都保持一致。

二、高可用保障


同城雙機房部署


分為主機房和從機房，寫入都在主機房，讀取則由兩個機房分擔。從而有效保證單機房故障時，能快速恢復。


豐富的降級手段

全鏈路的業務監控

高可用保障建設完成後，迎來了 TFBOYS 在美拍的四場直播，這四場直播峰值同時在線人數達到近百萬，共 2860萬人次觀看，2980萬評論，26.23億次點讚，直播期間，系統穩定運行，成功抗住壓力。

使用長連接替換短連接輪詢方案


長連接整體架構圖如下

詳細說明：

客戶端在使用長連接前，會調用路由服務，獲取連接層IP，路由層特性：a. 可以按照百分比灰度；b. 可以對 uid，deviceId，版本進行黑白名單設置。黑名單：不允許使用長連接；白名單：即使長連接關閉或者不在灰度範圍內，也允許使用長連接。這兩個特性保證了我們長短連接切換的順利進行；

客戶端的特性：a. 同時支持長連接和短連接，可根據路由服務的配置來決定；b. 自動降級，如果長連接同時三次連接不上，自動降級為短連接；c. 自動上報長連接性能數據；

連接層只負責與客戶端保持長連接，沒有任何推送的業務邏輯。從而大大減少重啟的次數，從而保持用戶連接的穩定；

推送層存儲用戶與直播間的訂閱關係，負責具體推送。整個連接層與推送層與直播間業務無關，不需要感知到業務的變化；

長連接業務模塊用於用戶進入直播間的驗證工作；

服務端之間的通訊使用基礎研發團隊研發的tardis框架來進行服務的調用，該框架基於 gRPC，使用 etcd 做服務發現；

長連接消息模型

我們採用了訂閱推送模型，下圖為基本的介紹

舉例說明:用戶1訂閱了A直播，A直播有新的消息


如果是大直播間（訂閱用戶多），那麼推送層與連接層的告知/拉取模型，就會自動降級為廣播模型。如下圖所示

我們經歷客戶端三個版本的迭代，實現了兩端（Android 與 iOS）長連接對短連接的替換，因為有灰度和黑白名單的支持，替換非常平穩，用戶無感知。

總結與展望


回顧了系統的發展過程，達到了原定的前中期使用輪詢，中後期使用長連接的預定目標，實踐了原定的平衡演進的原則。從發展來看，未來計劃要做的事情有

號外：


美圖架構，專注於虛擬化平臺建設、流媒體、雲存儲、千萬同時在線的通訊服務、音視頻編解碼等基礎設施建設，現急需相關領域愛好者加入，工作地點可自由選擇北京、廈門、深圳，待遇從優，美女多多。現緊缺崗位如下：

有興趣者請聯繫：yt@meitu.com or wjb@meitu.com or zl3@meitu.com

推薦閱讀


54 個架構案例  49 位作者   2 年打磨

『高可用架構』第 1 卷  10 月上市

點擊 閱讀原文 搶先預訂

高可用架構

改變網際網路的構建方式

相關焦點

  • bilibili 架構師 高並發實時彈幕系統的實戰之路
    前言：隨著直播的發展，直播彈幕也逐漸火爆起來。在架構設計上，高穩定、高可用、低延遲是一款直播彈幕系統必備的三要素。
  • bilibili 高並發實時彈幕系統的實戰之路 架構師實踐日
    編者按：隨著直播的發展，直播彈幕也逐漸火爆起來。在架構設計上，高穩定、高可用、低延遲是一款直播彈幕系統必備的三要素。
  • 17次直播回看,50節架構師訓練營幹貨重放 | 架構師之路
    第一件，把多年業務架構經驗，以在線直播的形式，和大家進行分享，不知不覺，全年竟然播了17期；第二件，把多年系統架構經驗，以在線訓練營的形式，和大家進行分享，大概50講。很多朋友問，直播和訓練營，能不能回看。
  • 深度解密系統架構背後的技術,雲+社區沙龍online「架構演進」乾貨整理
    既要應對龐大的用戶量、日均數十億 PV 的高並發、PB 級別的數據存儲等問題的挑戰，同時又要求保證系統的高可用和彈性伸縮，並且能夠根據需要進行快速迭代擴展，令人頭疼的系統架構到底應該怎麼做？ 多年發展下，網際網路架構經歷了從簡到繁的演進過程，從單體架構到集群架構、分布式架構再到微服務架構，每一種架構都是為了解決問題而生。
  • KuAI平臺 | 模型在線推理系統的高可用設計
    本文提出一種分布式機器學習模型在線推理系統的完整技術方案，該系統主要採用CPU/GPU 計算節點來提供推理任務的基礎算力，通過Docker容器技術封裝、打包模型推理任務，將不同服務的運行環境完全隔離，並藉助Kubernetes進行服務編排，提供服務的分布式容災和資源的彈性伸縮功能，同時結合模型倉庫、容器鏡像倉庫、系統/服務狀態監控、服務註冊/訂閱、可視化面板等功能模塊使算法模型與服務架構解耦
  • 物聯網系統架構介紹
    如何搭建起一個物聯網系統框架呢？它的技術架構又是怎麼樣呢？物聯網終端設備軟體系統架構常見系統框架的總結下來主要存在如下2種： 帶RTOS的（處理複雜的業務場景，場景裡面通過需要多個事務並行協同完成工作）和不帶RTOS的（通常處理的業務場景較單一）不帶RTOS設備終端系統框架：
  • Linux 伺服器高並發調優實戰
    下面就從幾方面來調整使Linux系統能夠支持高並發環境。iptables相關如非必須，關掉或卸載iptables防火牆，並阻止kernel加載iptables模塊。這些模塊會影響並發性能。通過上述步驟，就為支持高並發TCP連接處理的通訊處理程序解除關於打開文件數量方面的系統限制。內核TCP參數方面Linux系統下，TCP連接斷開後，會以TIME_WAIT狀態保留一定的時間，然後才會釋放埠。
  • Linux伺服器高並發調優實戰
    下面就從幾方面來調整使Linux系統能夠支持高並發環境。iptables相關如非必須，關掉或卸載iptables防火牆，並阻止kernel加載iptables模塊。這些模塊會影響並發性能。所以，如果有上述問題存在，就只能去打開/etc/profile腳本文件，在文件中查找是否使用了ulimit-n限制了用戶可同時打開的最大文件數量，如果找到，則刪除這行命令，或者將其設置的值改為合適的值，然後保存文件，用戶退出並重新登錄系統即可。通過上述步驟，就為支持高並發TCP連接處理的通訊處理程序解除關於打開文件數量方面的系統限制。
  • Greenplum架構最詳解讀(內含視頻)
    >在本次活動中，來自Greenplum全球總監楊瑜介紹了一些包括資料庫、資料庫管理系統、關係型資料庫、關係模型等基本概念；詳細解讀了Greenplum的整體架構、存儲管理、索引、查詢執行、事務與日誌等內容；直播室裡氣氛熱烈，大家都紛紛表示，此次活動演講內容乾貨滿滿，收穫多多。沒有參加活動的小夥伴也不要氣餒，這篇文章幫你牢固掌握本次直播的所有要點。
  • 彈幕語言是如何變色的?
    彈幕語言的含金量和它所寄生的視頻內容有關，如果直播平臺野蠻生長，朝著「抓眼球」發展，彈幕也會不斷秀下限。
  • 必看的Linux伺服器高並發調優實戰
    下面就從幾方面來調整使Linux系統能夠支持高並發環境。iptables相關如非必須，關掉或卸載iptables防火牆，並阻止kernel加載iptables模塊。這些模塊會影響並發性能。所以，如果有上述問題存在，就只能去打開/etc/profile腳本文件，在文件中查找是否使用了ulimit-n限制了用戶可同時打開的最大文件數量，如果找到，則刪除這行命令，或者將其設置的值改為合適的值，然後保存文件，用戶退出並重新登錄系統即可。通過上述步驟，就為支持高並發TCP連接處理的通訊處理程序解除關於打開文件數量方面的系統限制。
  • 原創譯文Facebook如何實現80萬人同時在線觀看直播
    Facebook需要為數百萬個同時進行的直播提供服務而不出現故障，同時還要為觀看直播的數百萬個觀眾提供支持，而且還要處理不同設備和服務商之間流暢連接的問題。Cox說「這確實是個很棘手的技術問題，需要強大的基礎設施。」大家是不是很好奇這些基礎設施的問題是如何解決的呢？
  • 【連載】每秒百萬級CC攻擊----DDOS 防禦事件(二)
    下面我祥細講講CC攻擊之後有什麼表現，如何防禦，有Cc有什麼攻擊類型。早些年，最早做視頻直播的是在韓國，他們在中國周邊，也就是延邊那些地區招了一些會說韓語的女孩子陪韓國大叔聊天，韓國大叔就會給禮品。一天收入好幾個億韓幣，後來知道的人多了，競爭就大了。韓國那邊就要上搜尋引擎打廣告（類似百度競價），只要排名第一位，就被人攻擊，主要手段是Cc攻擊。
  • 聊聊Android系統架構
    今天說點基礎內容——系統架構。
  • 系統吞吐量、TPS(QPS)、用戶並發量、性能測試概念和公式
    單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。公司員工為1000人，平均每個員上登錄籤到系統的時長為5分鐘。可以用下面的方法計算。1、 相應時間2、 伺服器資源使用情況是否合理3、 應用伺服器和資料庫資源使用是否合理4、 系統能否實現擴展5、 系統最多支持多少用戶訪問、系統最大業務處理量是多少6、 系統性能可能存在的瓶頸在哪裡7、 更換那些設備可以提高性能8、 系統能否支持7×24小時的業務訪問再次，站在開發（設計）人員角度去考慮。
  • 帶你實現完整的 iOS 視頻彈幕系統
    彈幕誕生於日本的視頻平臺，後來被B站這種短視頻平臺引入到國內，並在國內發展壯大。後來逐漸被長視頻平臺所接受，現在視頻相關的應用基本上都會有彈幕。但是長視頻彈幕和B站這類的短視頻彈幕還不太一樣，短視頻平臺有自己特有的彈幕文化，所以彈幕更注重和用戶的互動。
  • 推薦系統架構與算法流程詳解
    ，那麼推薦系統的作用就是建立更加有效率的連接，推薦系統可以更有效率的連接用戶與內容和服務，節約了大量的時間和成本。一個推薦系統的實時性要求越高、訪問量越大那麼這個推薦系統的架構就會越複雜。推薦系統的整體框架
  • 在線直播 | TI 和 Littelfuse 安全、可靠、高效的電源系統解決方案
    本次直播將讓工程師理解、掌握第三代功率器件 GaN 和 SiC 的工藝和技術特點及相關應用，並且理解和把握前沿的電路保護技術及相關應用方案2. 提供面向 5G、光伏以及新能源汽車等行業的電源系統應用於解決方案，讓工程師在工作中得心應手3.
  • 支付系統高可用架構設計實戰
    對於一個功能和數據量不斷增加的應用，要保持比較高的可用性並非易事。為了實現高可用，付錢拉從避免單點故障、保證應用自身的高可用、解決交易量增長等方面做了許多探索和實踐。儘可能避免故障> > > >設計可容錯的系統比如重路由，對於用戶支付來說，用戶並不關心自己的錢具體是從哪個通道支付出去的，用戶只關心成功與否。付錢拉連接30多個通道，有可能A通道支付不成功，這個時候就需要動態重路由到B或者C通道，這樣就可以通過系統重路由避免用戶支付失敗，實現支付容錯。
  • 系統架構師—著眼於系統的「技術實現」
    關注並標星大同學吧每天1次，打卡閱讀了解崗位職責和必備技能今天是大同學吧崗位專欄第56期職位介紹之系統架構師系統架構師是一個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節、掃清主要難點的技術人員。