1、內容概述
直播彈幕是直播系統的核心功能之一。如何迅速作出一個有很好擴展性的彈幕系統？如何應對業務迅速發展？相信很多工程師/架構師都有自己的想法。
本文作者是美拍的架構師，經歷了直播彈幕從無到有，從小到大的過程，藉此文為大家分享構建彈幕系統的經驗，希望能為正在開發或正打算開發彈幕、消息推送、IM聊天等系統的技術同行帶來一些啟發。
直播彈幕指直播間的用戶，禮物，評論，點贊等消息，是直播間交互的重要手段。美拍直播彈幕系統從 2015 年 11 月到現在，經過了三個階段的演進，目前能支撐百萬用戶同時在線。比較好地詮釋了根據項目的發展階段進行平衡演進的過程。這三個階段分別是快速上線、高可用保障體系建設、長連接演進。具體我將在正文中展開，請繼續往下閱讀。
（本文同步發佈於：http://www.52im.net/thread-1236-1-1.html ）
2、關於作者
王靜波
- 畢業於西安交通大學，曾任職於網易和新浪微博，微博工作期間負責開放平台業務和技術體系建設；
- 2015年9月加入美圖，就職於架構平台部，目前負責部分核心業務和基礎設施的研發，包括彈幕、Feed、任務調度和質量監控體系等；
- 十餘年的後端研發經歷，擁有豐富的後端研發經驗，對於構建高可用、高並發的系統有較多實踐經驗。
3、起步——快速上線
3.1 消息模型
美拍直播彈幕系統在設計初期的核心要求是：
1）快速上線；
2）並能支撐百萬用戶同時在線。
基於這兩點，我們策略是前中期 HTTP 輪詢方案，中後期替換為長連接方案。因此在業務團隊進行 HTTP 方案研發的同時，基礎研發團隊也緊鑼密鼓地開發長連接系統。
直播間消息，相對於IM即時通訊的場景，有其幾個特點：
1）消息要求更及時：過時的消息對於用戶來說不重要；
2）鬆散的群聊：用戶隨時進群，隨時退群；
3）歷史消息不需要重發：用戶進群後，離線期間（接聽電話）的消息不需要重發。
對於用戶來說，在直播間有三個典型的操作：
1）進入直播間，拉取正在觀看直播的用戶列表；
2）接收直播間持續接收彈幕消息；
3）自己發消息。
我們把禮物，評論，用戶的數據都當做消息來看待。
經過考慮選擇了 Redis 的 sortedset 存儲消息，消息模型如下：
1）用戶發消息：通過 Zadd，其中 score 消息的相對時間；
2）接收直播間的消息：通過 ZrangeByScore 操作，兩秒一次輪詢；
3）進入直播間：獲取用戶的列表，通過 Zrange 操作來完成。
因此總的流程是：
1）寫消息流程是:前端機 -> Kafka -> 處理機 -> Redis；
2）讀消息流程是:前端 -> Redis。
不過這裡有一個隱藏的並發問題：用戶可能丟消息。
如上圖所示，某個用戶從第6號評論開始拉取，同時有兩個用戶在發表評論，分別是10,11號評論。如果11號評論先寫入，用戶剛好把6,7,8,9,11號拉走，用戶下次再拉取消息，就從12號開始拉取，結果是：用戶沒有看到10號消息。
為了解決這個問題，我們加上了兩個機制:
1）在前端機：同一個直播間的同一種消息類型，寫入 Kafka 的同一個 partition；
2）在處理機：同一個直播間的同一種消息類型，通過 synchronized 保證寫入 Redis 的串列。
消息模型及並發問題解決後，開發就比較順暢，系統很快就上線，達到預先預定目標。
4、問題——上線後暴露的問題及解決方法
上線後，隨著量的逐漸增加，系統陸續暴露出三個比較嚴重的問題，我們一一進行了解決。
4.1 問題一：消息串列寫入 Redis，容易堆積在 Kafka 中且消息延遲較大
消息串列寫入 Redis，如果某個直播間消息量很大，那麼消息會堆積在 Kafka 中，消息延遲較大。
解決辦法：
1）消息寫入流程優化：前端機-> Kafka -> 處理機 -> Redis；
2）前端機：如果延遲小，則只寫入一個 Kafka 的partion；如果延遲大，則這個直播的這種消息類型寫入 Kafka 的多個partion；
3）處理機：如果延遲小，加鎖串列寫入 Redis；如果延遲大，則取消鎖。因此有四種組合，四個檔位，分別是：
- 一個partion, 加鎖串列寫入 Redis, 最大並發度:1；
- 多個partition,加鎖串列寫入 Redis, 最大並發度:Kafka partion的個數；
- 一個partion, 不加鎖並行寫入 Redis, 最大並發度: 處理機的線程池個數；
- 多個partion, 不加鎖並行寫入 Redis，最大並發度: Kafka partition個數處理機線程池的個數。
4）延遲程度判斷：前端機寫入消息時，打上消息的統一時間戳，處理機拿到後，延遲時間 = 現在時間 - 時間戳；
5）檔位選擇：自動選擇檔位，粒度:某個直播間的某個消息類型。
4.2 問題二：redis slave 的性能瓶頸較大
用戶輪詢最新消息，需要進行 Redis 的 ZrangByScore 操作，redis slave 的性能瓶頸較大。
解決辦法:
本地緩存：前端機每隔1秒左右取拉取一次直播間的消息，用戶到前端機輪詢數據時，從本地緩存讀取數據；
消息的返回條數根據直播間的大小自動調整：小直播間返回允許時間跨度大一些的消息，大直播間則對時間跨度以及消息條數做更嚴格的限制。
解釋：
這裡本地緩存與平常使用的本地緩存問題，有一個最大區別：成本問題。如果所有直播間的消息都進行緩存，假設同時有1000個直播間，每個直播間5種消息類型，本地緩存每隔1秒拉取一次數據，40台前端機，那麼對 Redis 的訪問QPS是 1000 * 5 * 40 = 20萬。成本太高，因此我們只有大直播間才自動開啟本地緩存，小直播間不開啟。
4.3 問題三：彈幕數據回放時，會與直播的數據競爭 Redis 的 cpu 資源
彈幕數據也支持回放，直播結束後，這些數據存放於 Redis 中，在回放時，會與直播的數據競爭 Redis 的 cpu 資源。
解決辦法:
1）直播結束後，數據備份到 mysql；
2）增加一組回放的 Redis；
3）前端機增加回放的 local cache。
解釋：
回放時，讀取數據順序是: local cache -> Redis -> mysql。localcache 與回放 Redis 都可以只存某個直播某種消息類型的部分數據，有效控制容量；local cache與回放 Redis 使用SortedSet數據結構，這樣整個系統的數據結構都保持一致。
5、升級1——實現高可用保障
同城雙機房部署：
分為主機房和從機房，寫入都在主機房，讀取則由兩個機房分擔。從而有效保證單機房故障時，能快速恢復。
豐富的降級手段：
全鏈路的業務監控：
高可用保障建設完成後，迎來了 TFBOYS 在美拍的四場直播，這四場直播峰值同時在線人數達到近百萬，共 2860萬人次觀看，2980萬評論，26.23億次點贊，直播期間，系統穩定運行，成功抗住壓力。
6、升級2——使用長連接替換短連接輪詢方案
6.1 長連接架構
長連接整體架構圖如下：
詳細說明：
1）客戶端在使用長連接前，會調用路由服務，獲取連接層IP，路由層特性（a. 可以按照百分比灰度；b. 可以對 uid、deviceId、版本進行黑白名單設置）：
- 黑名單：不允許使用長連接；
- 白名單：即使長連接關閉或者不在灰度範圍內，也允許使用長連接。
這兩個特性保證了我們長短連接切換的順利進行。
2）客戶端的特性：
- a. 同時支持長連接和短連接，可根據路由服務的配置來決定；
- b. 自動降級，如果長連接同時三次連接不上，自動降級為短連接；
- c. 自動上報長連接性能數據；
3）連接層只負責與客戶端保持長連接，沒有任何推送的業務邏輯。從而大大減少重啟的次數，從而保持用戶連接的穩定；
4）推送層存儲用戶與直播間的訂閱關係，負責具體推送。整個連接層與推送層與直播間業務無關，不需要感知到業務的變化；
5）長連接業務模塊用於用戶進入直播間的驗證工作；
6）服務端之間的通訊使用基礎研發團隊研發的tardis框架來進行服務的調用，該框架基於 gRPC，使用 etcd 做服務發現。
6.2 長連接消息模型
我們採用了訂閱推送模型，下圖為基本的介紹：
舉例說明：用戶1訂閱了A直播，A直播有新的消息
1）推送層查詢訂閱關係後，知道有用戶1訂閱了A直播，同時知道用戶1在連接層1這個節點上，那麼就會告知連接層有新的消息；
2）連接層1收到告知消息後，會等待一小段時間（毫秒級），再拉取一次用戶1的消息，然後推送給用戶1。
如果是大直播間（訂閱用戶多），那麼推送層與連接層的告知/拉取模型，就會自動降級為廣播模型。
如下圖所示：
我們經歷客戶端三個版本的迭代，實現了兩端（Android 與 iOS）長連接對短連接的替換，因為有灰度和黑白名單的支持，替換非常平穩，用戶無感知。
7、總結與展望
回顧了系統的發展過程，達到了原定的前中期使用輪詢，中後期使用長連接的預定目標，實踐了原定的平衡演進的原則。
從未來的發展來看，計劃要做的事情有：
1）針對機房在北京，南方某些地區會存在連接時間長的情況（我們如何讓長連接更靠近用戶？）；
2）消息模型的進一步演進。
（本文同步發佈於：http://www.52im.net/thread-1236-1-1.html）
附錄：更多推送技術文章
《iOS的推送服務APNs詳解：設計思路、技術原理及缺陷等》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《Android端消息推送總結：實現原理、心跳保活、遇到的問題等》
《掃盲貼：認識MQTT通信協議》
《一個基於MQTT通信協議的完整Android推送Demo》
《IBM技術經理訪談：MQTT協議的制定歷程、發展現狀等》
《求教android消息推送：GCM、XMPP、MQTT三種方案的優劣》
《移動端實時消息推送技術淺析》
《掃盲貼：淺談iOS和Android後台實時消息推送的原理和區別》
《絕對乾貨：基於Netty實現海量接入的推送服務技術要點》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《為何微信、QQ這樣的IM工具不使用GCM服務推送消息？》
《極光推送系統大規模高並發架構的技術實踐分享》
《從HTTP到MQTT：一個基於位置服務的APP數據通信實踐概述》
《魅族2500萬長連接的實時消息推送架構的技術實踐分享》
《專訪魅族架構師：海量長連接的實時消息推送系統的心得體會》
《深入的聊聊Android消息推送這件小事》
《基於WebSocket實現Hybrid移動應用的消息推送實踐(含代碼示例)》
《一個基於長連接的安全可擴展的訂閱/推送服務實現思路》
《實踐分享：如何構建一套高可用的移動端消息推送系統？》
《Go語言構建千萬級在線的高並發消息推送系統實踐(來自360公司)》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《百萬在線的美拍直播彈幕系統的實時推送技術實踐之路》
>>更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1236-1-1.html）
推薦閱讀：
评论留言