建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
直播彈幕是直播系統(tǒng)的核心功能之一。如何迅速作出一個(gè)有很好擴(kuò)展性的彈幕系統(tǒng)？如何應(yīng)對(duì)業(yè)務(wù)迅速發(fā)展？相信很多工程師/架構(gòu)師都有自己的想法。
長(zhǎng)洲ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書(shū)銷(xiāo)售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話(huà)聯(lián)系或者加微信：18980820575（備注：SSL證書(shū)合作）期待與您的合作！
本文作者美拍架構(gòu)師王靜波經(jīng)歷了直播彈幕系統(tǒng)從無(wú)到有，從小到大的過(guò)程并對(duì)構(gòu)建彈幕系統(tǒng)的經(jīng)驗(yàn)進(jìn)行了總結(jié)。
直播彈幕指直播間的用戶(hù)，禮物，評(píng)論，點(diǎn)贊等消息，是直播間交互的重要手段。
美拍直播彈幕系統(tǒng)從 2015 年 11 月到現(xiàn)在，經(jīng)過(guò)了三個(gè)階段的演進(jìn)，目前能支撐百萬(wàn)用戶(hù)同時(shí)在線(xiàn)。
本文比較好地詮釋了根據(jù)項(xiàng)目的發(fā)展階段，直播彈幕系統(tǒng)進(jìn)行平衡演進(jìn)的過(guò)程。這三個(gè)階段分別是快速上線(xiàn)，高可用保障體系建設(shè)，長(zhǎng)連接演進(jìn)。
快速上線(xiàn)
消息模型
美拍直播彈幕系統(tǒng)在設(shè)計(jì)初期的核心要求是：快速上線(xiàn)，并能支撐百萬(wàn)用戶(hù)同時(shí)在線(xiàn)。
基于這兩點(diǎn)，我們的策略是前中期使用 HTTP 輪詢(xún)方案，中后期替換為長(zhǎng)連接方案。
因此在業(yè)務(wù)團(tuán)隊(duì)進(jìn)行 HTTP 方案研發(fā)的同時(shí)，基礎(chǔ)研發(fā)團(tuán)隊(duì)也緊鑼密鼓地開(kāi)發(fā)長(zhǎng)連接系統(tǒng)。
直播間消息，相對(duì)于 IM 的場(chǎng)景，有如下幾個(gè)特點(diǎn)：
- 消息要求及時(shí)，過(guò)時(shí)的消息對(duì)于用戶(hù)來(lái)說(shuō)不重要。
- 松散的群聊，用戶(hù)隨時(shí)進(jìn)群，隨時(shí)退群。
- 用戶(hù)進(jìn)群后，離線(xiàn)期間（接聽(tīng)電話(huà)）的消息不需要重發(fā)。
對(duì)于用戶(hù)來(lái)說(shuō)，在直播間有三個(gè)典型的操作：
- 進(jìn)入直播間，拉取正在觀(guān)看直播的用戶(hù)列表。
- 接收直播間持續(xù)發(fā)布的彈幕消息。
- 自己發(fā)消息。
我們把禮物，評(píng)論，用戶(hù)的數(shù)據(jù)都當(dāng)做消息來(lái)看待。
經(jīng)過(guò)考慮選擇了 Redis 的 sortedset 存儲(chǔ)消息，消息模型如下：
- 用戶(hù)發(fā)消息，通過(guò) Zadd，其中 score 消息的相對(duì)時(shí)間。
- 接收直播間的消息，通過(guò) ZrangeByScore 操作，兩秒一次輪詢(xún)。
- 進(jìn)入直播間，獲取用戶(hù)的列表，通過(guò) Zrange 操作來(lái)完成。
因此總的流程是：
- 寫(xiě)消息流程是: 前端機(jī) -> Kafka -> 處理機(jī) -> Redis。
- 讀消息流程是: 前端 -> Redis。
不過(guò)這里有一個(gè)隱藏的并發(fā)問(wèn)題：用戶(hù)可能丟消息。
如上圖所示，某個(gè)用戶(hù)從第 6 號(hào)評(píng)論開(kāi)始拉取，同時(shí)有兩個(gè)用戶(hù)在發(fā)表評(píng)論，分別是 10，11 號(hào)評(píng)論。
如果 11 號(hào)評(píng)論先寫(xiě)入，用戶(hù)剛好把 6，7，8，9，11 號(hào)拉走，用戶(hù)下次再拉取消息，就從 12 號(hào)開(kāi)始拉取，結(jié)果是：用戶(hù)沒(méi)有看到 10 號(hào)消息。
為了解決這個(gè)問(wèn)題，我們加上了兩個(gè)機(jī)制：
- 在前端機(jī)，同一個(gè)直播間的同一種消息類(lèi)型，寫(xiě)入 Kafka 的同一個(gè) partition。
- 在處理機(jī)，同一個(gè)直播間的同一種消息類(lèi)型，通過(guò) synchronized 保證寫(xiě)入 Redis 的串行。
消息模型及并發(fā)問(wèn)題解決后，開(kāi)發(fā)就比較順暢，系統(tǒng)很快就實(shí)現(xiàn)上線(xiàn)，達(dá)到了預(yù)先設(shè)定的目標(biāo)。
上線(xiàn)后暴露問(wèn)題的解決
上線(xiàn)后，隨著消息量的逐漸增加，系統(tǒng)陸續(xù)暴露出三個(gè)比較嚴(yán)重的問(wèn)題，我們一一進(jìn)行了解決。
問(wèn)題一：消息串行寫(xiě)入 Redis，如果某個(gè)直播間消息量很大，那么消息會(huì)堆積在 Kafka 中，消息延遲較大。
解決辦法：
- 消息寫(xiě)入流程：前端機(jī)-> Kafka -> 處理機(jī) -> Redis。
- 前端機(jī)：如果延遲小，則只寫(xiě)入一個(gè) Kafka 的 partion；如果延遲大，則這個(gè)直播的這種消息類(lèi)型寫(xiě)入 Kafka 的多個(gè) partion。
- 處理機(jī)：如果延遲小，加鎖串行寫(xiě)入 Redis；如果延遲大，則取消鎖。
因此有四種組合，四個(gè)檔位，分別是：
- 一個(gè) partion，加鎖串行寫(xiě)入 Redis, ***并發(fā)度：1。
- 多個(gè) partition，加鎖串行寫(xiě)入 Redis，***并發(fā)度：Kafka partion的個(gè)數(shù)。
- 一個(gè) partion，不加鎖并行寫(xiě)入 Redis，***并發(fā)度：處理機(jī)的線(xiàn)程池個(gè)數(shù)。
- 多個(gè) partion，不加鎖并行寫(xiě)入 Redis，***并發(fā)度: Kafka partition 個(gè)數(shù)處理機(jī)線(xiàn)程池的個(gè)數(shù)。
- 延遲程度判斷：前端機(jī)寫(xiě)入消息時(shí)，打上消息的統(tǒng)一時(shí)間戳，處理機(jī)拿到后，延遲時(shí)間 = 現(xiàn)在時(shí)間 - 時(shí)間戳。
- 檔位選擇：自動(dòng)選擇檔位，粒度：某個(gè)直播間的某個(gè)消息類(lèi)型。
問(wèn)題二：用戶(hù)輪詢(xún)***消息，需要進(jìn)行 Redis 的 ZrangByScore 操作，redis slave 的性能瓶頸較大。
解決辦法：
- 本地緩存，前端機(jī)每隔 1 秒左右拉取一次直播間的消息，用戶(hù)到前端機(jī)輪詢(xún)數(shù)據(jù)時(shí)，從本地緩存讀取數(shù)據(jù)。
- 消息的返回條數(shù)根據(jù)直播間的大小自動(dòng)調(diào)整，小直播間返回允許時(shí)間跨度大一些的消息，大直播間則對(duì)時(shí)間跨度以及消息條數(shù)做更嚴(yán)格的限制。
解釋?zhuān)哼@里本地緩存與平常使用的本地緩存，有一個(gè)***區(qū)別，就是考慮了成本問(wèn)題。
如果所有直播間的消息都進(jìn)行緩存，假設(shè)同時(shí)有 1000 個(gè)直播間，每個(gè)直播間 5 種消息類(lèi)型，本地緩存每隔 1 秒拉取一次數(shù)據(jù)，40 臺(tái)前端機(jī)，那么對(duì) Redis 的訪(fǎng)問(wèn) QPS 是 1000 * 5 * 40 = 20 萬(wàn)。
成本太高，因此我們只有大直播間才自動(dòng)開(kāi)啟本地緩存，小直播間不開(kāi)啟。
問(wèn)題三：彈幕數(shù)據(jù)也支持回放，直播結(jié)束后，這些數(shù)據(jù)存放于 Redis 中，在回放時(shí)，會(huì)與直播的數(shù)據(jù)競(jìng)爭(zhēng) Redis 的 CPU 資源。
解決辦法：
- 直播結(jié)束后，數(shù)據(jù)備份到 MySQL。
- 增加一組回放的 Redis。
- 前端機(jī)增加回放的 local cache。
解釋?zhuān)夯胤艜r(shí)，讀取數(shù)據(jù)順序是: local cache -> Redis -> mysql。localcache 與回放 Redis 都可以只存某個(gè)直播某種消息類(lèi)型的部分?jǐn)?shù)據(jù)，有效控制容量；local cache與回放 Redis 使用 sortedset 數(shù)據(jù)結(jié)構(gòu)，這樣整個(gè)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)都保持一致。
高可用保障
同城雙機(jī)房部署
雙機(jī)房分為主機(jī)房和從機(jī)房，寫(xiě)入都在主機(jī)房，讀取則由兩個(gè)從機(jī)房分擔(dān)。從而有效保證單機(jī)房故障時(shí)，能快速恢復(fù)。
豐富的降級(jí)手段
全鏈路的業(yè)務(wù)監(jiān)控
高可用保障建設(shè)完成后，迎來(lái)了 TFBOYS 在美拍的四場(chǎng)直播，這四場(chǎng)直播峰值同時(shí)在線(xiàn)人數(shù)達(dá)到近百萬(wàn)，共 2860 萬(wàn)人次觀(guān)看，2980 萬(wàn)評(píng)論，26.23 億次點(diǎn)贊，直播期間，系統(tǒng)穩(wěn)定運(yùn)行，成功抗住壓力。
使用長(zhǎng)連接替換短連接輪詢(xún)方案
長(zhǎng)連接整體架構(gòu)圖
詳細(xì)說(shuō)明：
- 客戶(hù)端在使用長(zhǎng)連接前，會(huì)調(diào)用路由服務(wù)，獲取連接層IP，路由層特性：a.可以按照百分比灰度；b.可以對(duì) uid，deviceId，版本進(jìn)行黑白名單設(shè)置。黑名單：不允許使用長(zhǎng)連接；白名單：即使長(zhǎng)連接關(guān)閉或者不在灰度范圍內(nèi)，也允許使用長(zhǎng)連接。這兩個(gè)特性保證了我們長(zhǎng)短連接切換的順利進(jìn)行。
- 客戶(hù)端的特性：a.同時(shí)支持長(zhǎng)連接和短連接，可根據(jù)路由服務(wù)的配置來(lái)決定；b.自動(dòng)降級(jí)，如果長(zhǎng)連接同時(shí)三次連接不上，自動(dòng)降級(jí)為短連接；c.自動(dòng)上報(bào)長(zhǎng)連接性能數(shù)據(jù)。
- 連接層只負(fù)責(zé)與客戶(hù)端保持長(zhǎng)連接，沒(méi)有任何推送的業(yè)務(wù)邏輯。從而大大減少了重啟的次數(shù)，從而保持用戶(hù)連接的穩(wěn)定。
- 推送層存儲(chǔ)用戶(hù)與直播間的訂閱關(guān)系，負(fù)責(zé)具體推送。整個(gè)連接層與推送層與直播間業(yè)務(wù)無(wú)關(guān)，不需要感知到業(yè)務(wù)的變化。
- 長(zhǎng)連接業(yè)務(wù)模塊用于用戶(hù)進(jìn)入直播間的驗(yàn)證工作。
- 服務(wù)端之間的通訊使用基礎(chǔ)研發(fā)團(tuán)隊(duì)研發(fā)的 tardis 框架來(lái)進(jìn)行服務(wù)的調(diào)用，該框架基于 gRPC，使用 etcd 做服務(wù)發(fā)現(xiàn)。
長(zhǎng)連接消息模型
我們采用了訂閱推送模型，下圖為基本的介紹：
舉例說(shuō)明，用戶(hù) 1 訂閱了 A 直播，A 直播有新的消息：
- 推送層查詢(xún)訂閱關(guān)系后，知道有用戶(hù) 1 訂閱了 A 直播，同時(shí)知道用戶(hù) 1 在連接層 1 這個(gè)節(jié)點(diǎn)上，那么就會(huì)告知連接層有新的消息。
- 連接層 1 收到告知消息后，會(huì)等待一小段時(shí)間（毫秒級(jí)），再拉取一次用戶(hù) 1 的消息，然后推送給用戶(hù) 1。
如果是大直播間（訂閱用戶(hù)多），那么推送層與連接層的告知/拉取模型，就會(huì)自動(dòng)降級(jí)為廣播模型。如下圖所示：
我們經(jīng)歷了客戶(hù)端三個(gè)版本的迭代，實(shí)現(xiàn)了兩端（Android 與 iOS）長(zhǎng)連接對(duì)短連接的替換，因?yàn)橛谢叶群秃诎酌麊蔚闹С?，替換非常平穩(wěn)，用戶(hù)無(wú)感知。
總結(jié)與展望
回顧了系統(tǒng)的發(fā)展過(guò)程，達(dá)到了原定的前中期使用輪詢(xún)，中后期使用長(zhǎng)連接的預(yù)定目標(biāo)，實(shí)踐了原定的平衡演進(jìn)的原則。
從發(fā)展來(lái)看，未來(lái)計(jì)劃要做的事情有：
- 針對(duì)機(jī)房在北京，南方某些地區(qū)會(huì)存在連接時(shí)間長(zhǎng)的情況。我們?nèi)绾巫岄L(zhǎng)連接更靠近用戶(hù)。
- 消息模型的進(jìn)一步演進(jìn)。
王靜波，畢業(yè)于西安交通大學(xué)，曾任職于網(wǎng)易和新浪微博，微博工作期間負(fù)責(zé)開(kāi)放平臺(tái)業(yè)務(wù)和技術(shù)體系建設(shè)。2015 年 9 月加入美圖，就職于架構(gòu)平臺(tái)部，目前負(fù)責(zé)部分核心業(yè)務(wù)和基礎(chǔ)設(shè)施的研發(fā)工作，包括彈幕服務(wù)、Feed 服務(wù)、任務(wù)調(diào)度和質(zhì)量監(jiān)控體系等。十余年的后端研發(fā)經(jīng)歷，擁有豐富的后端研發(fā)經(jīng)驗(yàn)，對(duì)于構(gòu)建高可用、高并發(fā)的系統(tǒng)有較多實(shí)踐經(jīng)驗(yàn)。歡迎通過(guò) wjb@meitu.com 跟他交流。
新聞標(biāo)題：支撐百萬(wàn)用戶(hù)同時(shí)在線(xiàn)的高并發(fā)直播彈幕系統(tǒng)是如何煉成的？
網(wǎng)頁(yè)網(wǎng)址：http://m.5511xx.com/article/cocghio.html
