百度直播消息服務(wù)架構(gòu)實(shí)踐

1. 同時(shí)參與人數(shù)不同： 群聊的參與人數(shù)上千人就是很大的群了；但對(duì)于高熱度的大型直播場(chǎng)景，例如國(guó)慶、閱兵、春晚等，單直播間累計(jì)用戶(hù)是百萬(wàn)甚至千萬(wàn)量級(jí)的集合，同時(shí)在線(xiàn)人數(shù)可達(dá)數(shù)百萬(wàn)人。
2. 用戶(hù)與群和直播間的關(guān)系不同： 用戶(hù)進(jìn)群退群，是相對(duì)低頻的操作，用戶(hù)集合相對(duì)固定，用戶(hù)進(jìn)出的變更頻度不會(huì)特別高；而用戶(hù)進(jìn)出直播間，是非常頻繁的，高熱度直播的單直播間每秒面臨上萬(wàn)用戶(hù)的進(jìn)出變更。
3. 持續(xù)時(shí)間不同： 群聊建立后，聊天持續(xù)時(shí)間可能比較長(zhǎng)，幾天到數(shù)月都有；而直播間大部分持續(xù)不超過(guò)幾個(gè)小時(shí)。

1. 單直播間每秒上萬(wàn)用戶(hù)的進(jìn)出變更；實(shí)際進(jìn)入直播間峰值不超過(guò)2萬(wàn)QPS，退出也不超過(guò)2萬(wàn)QPS。
2. 單直播間同時(shí)數(shù)百萬(wàn)用戶(hù)在線(xiàn)
3. 單直播間累計(jì)用戶(hù)達(dá)千萬(wàn)量級(jí)

1. 實(shí)時(shí)性： 如果消息服務(wù)端做簡(jiǎn)單消峰處理，峰值消息的堆積，會(huì)造成整體消息延時(shí)增大，且延時(shí)可能產(chǎn)生很大的累積效應(yīng)，消息與直播視頻流在時(shí)間線(xiàn)上產(chǎn)生很大的偏差，影響用戶(hù)觀看直播時(shí)互動(dòng)的實(shí)時(shí)性。
2. 端體驗(yàn)和性能： 端展示各類(lèi)用戶(hù)聊天和系統(tǒng)消息，一般一屏不超過(guò)10-20條；如果每秒有超過(guò)20條的消息下發(fā)，端上展示的消息基本會(huì)持續(xù)刷屏；再考慮到有禮物消息的特效等；大量的消息，對(duì)端的處理和展示，帶來(lái)持續(xù)高負(fù)荷。所以，對(duì)于一個(gè)長(zhǎng)時(shí)間觀看直播的用戶(hù)端來(lái)說(shuō)，如果出現(xiàn)持續(xù)的大量消息，端的消息消費(fèi)會(huì)有顯著的性能壓力，且過(guò)多消息會(huì)有累積效應(yīng)。

1. 實(shí)時(shí)性方面，端和端的消息要達(dá)到秒級(jí)；
2. 性能方面，消息服務(wù)能支持同一直播間內(nèi)百萬(wàn)以上用戶(hù)同時(shí)在線(xiàn)下發(fā)；
3. 而對(duì)于峰值的過(guò)多消息，丟棄是合理適當(dāng)?shù)奶幚矸绞剑?/span>
4. 基于合理的端用戶(hù)體驗(yàn)，單直播間內(nèi)每秒消息數(shù)假設(shè)不超過(guò)N條。

△圖1：群聊數(shù)據(jù)流及壓力點(diǎn)

1. 對(duì)于群group-1，分配一個(gè)群公共消息信箱group-mbox-1；
2. 群group-1內(nèi)的用戶(hù)user-1，由手機(jī)端APP-1上發(fā)出消息msg-1；
3. 服務(wù)端接收到消息msg-1，檢查user-1是否有權(quán)限，如有權(quán)限，將msg-1存儲(chǔ)到群信箱group-mbox-1，生成相應(yīng)msgID-1；
4. 服務(wù)端查詢(xún)group-1對(duì)應(yīng)的用戶(hù)列表groupUserList-1；
5. 基于groupUserList-1拆分出所有獨(dú)立群用戶(hù)：user-1、user-2。。。user-n；
6. 對(duì)于每一個(gè)用戶(hù)user-i來(lái)說(shuō)，需要查詢(xún)用戶(hù)user-i的所在設(shè)備device-i-1、device-i-2、device-i-m（因?yàn)橐粋€(gè)賬號(hào)可能登錄多個(gè)設(shè)備）；
7. 對(duì)于每個(gè)設(shè)備device-i-j來(lái)說(shuō)，長(zhǎng)連接通道都會(huì)建立一個(gè)獨(dú)立的長(zhǎng)連接connect-j以服務(wù)于該設(shè)備；但由于connect-j是由端上APP-1連接到長(zhǎng)連接服務(wù)的，具有動(dòng)態(tài)性，所以，查詢(xún)device-i-j與connect-j的對(duì)應(yīng)關(guān)系時(shí)，需要依賴(lài)一個(gè)路由服務(wù)route來(lái)完成查詢(xún)；
8. 在查得connect-j后，可以通過(guò)connect-j下發(fā)msg-1的通知groupmsg-notify-1；
9. 如果用戶(hù)user-i正在使用device-i-j的手機(jī)端APP-1，用戶(hù)user-i就可以立即從長(zhǎng)連接connect-j上收到msg-1的通知groupmsg-notify-1；
10. 在接收到groupmsg-notify-1后，手機(jī)端APP-1中的消息SDK根據(jù)端本地歷史消息記錄的最后一條消息latestMsg對(duì)應(yīng)的消息ID即latestMsgID，來(lái)向服務(wù)端發(fā)起拉消息請(qǐng)求fetchMsg，拉取group-1中從latestMsgID+1到最新的所有消息；
11. 服務(wù)端收到拉消息請(qǐng)求fetchMsg后，從group-mbox-1中取出latestMsgID+1到最新的所有消息，返回給端；如果消息過(guò)多，可能需要端分頁(yè)拉?。?/span>
12. 端APP-1拉取到group-1中從latestMsgID+1到最新的所有消息，可以做展示；在用戶(hù)在會(huì)話(huà)中閱讀后，需要設(shè)置所有新消息的已讀狀態(tài)或者會(huì)話(huà)已讀狀態(tài)。

1. 對(duì)于①拆分用戶(hù)列表和②查詢(xún)用戶(hù)對(duì)應(yīng)設(shè)備，如果存儲(chǔ)上將二者合并集中起來(lái)，也就是優(yōu)化直播間內(nèi)用戶(hù)列表的存儲(chǔ)，擴(kuò)展設(shè)備信息，可以減少一次user->device的百萬(wàn)QPS查詢(xún)，可以?xún)?yōu)化。
   
2. 對(duì)于④下行通知和⑤端拉取fetchMsg的可靠消息拉取模式，考慮到直播消息允許部分折損丟棄，可以只做單向消息下發(fā)，而不做拉取，對(duì)于大部分連接保持在線(xiàn)的用戶(hù)，也是可以接受的。所以可以?xún)?yōu)化，只保留下行通知（包含消息體），而舍棄端拉取。
   
3. 對(duì)于⑥消息設(shè)置已讀，直播場(chǎng)景下可以考慮簡(jiǎn)化舍棄。
   

1. 每個(gè)長(zhǎng)連接組播mcast有全局唯一的標(biāo)識(shí)mcastID。
2. 長(zhǎng)連接組播mcast支持創(chuàng)建、刪除、修改、查詢(xún)等管理操作。
3. 長(zhǎng)連接組播mcast是若干長(zhǎng)連接在線(xiàn)用戶(hù)的連接connect的集合。
4. 一個(gè)用戶(hù)user-i在設(shè)備device-i-j上，對(duì)于特定應(yīng)用APP-k來(lái)說(shuō)，建立唯一的一個(gè)長(zhǎng)連接connect-j-k；（此處暫時(shí)不區(qū)別登錄用戶(hù)和非登錄用戶(hù)）。
5. 長(zhǎng)連接組播mcast與組內(nèi)長(zhǎng)連接connect-j-k的關(guān)系維護(hù)，不需要額外的獨(dú)立存儲(chǔ)，是維護(hù)在每個(gè)長(zhǎng)連接服務(wù)的實(shí)例上。

1. 客戶(hù)端調(diào)用消息sdk加入mcast-m。
2. 消息sdk通過(guò)長(zhǎng)連接，發(fā)出上行請(qǐng)求mcastJoin（mcast-m）。
3. 業(yè)務(wù)層收到來(lái)自長(zhǎng)連接實(shí)例lcs-i上的連接connect-i的mcastJoin請(qǐng)求，校驗(yàn)mcast-m的合法性。
4. 業(yè)務(wù)層請(qǐng)求路由層建立基于組播mcast-m的組播路由mcastRoute-m，將長(zhǎng)連接實(shí)例lcs-i加入組播路由mcastRoute-m中。
5. 業(yè)務(wù)層請(qǐng)求長(zhǎng)連接服務(wù)層，請(qǐng)求mcastJoin所在長(zhǎng)連接實(shí)例lcs-i，將請(qǐng)求所在連接connect-i加入到mcastConnectList-m中。

1. 一條消息msg-1推送，目的地是ID為mcast-m組播；
2. 后端業(yè)務(wù)模塊根據(jù)目的mcast-m，做一致性hash選擇出mcast路由分發(fā)模塊實(shí)例mcastRouter- i，發(fā)送msg-1到mcastRouter-i；
3. mcast分發(fā)路由模塊實(shí)例mcastRouter-i，根據(jù)mcast-m的組播路由mcastRoute-m，查找所對(duì)應(yīng)的接入實(shí)例路由記錄列表mcastLcsList-m，拆分出mcast-m所有的長(zhǎng)連接接入實(shí)例lcs-1..lcs-M，分別并發(fā)發(fā)送msg-1到長(zhǎng)連接實(shí)例上；
4. 一個(gè)長(zhǎng)連接服務(wù)實(shí)例lcs-j，收到消息msg-1推送后，根據(jù)組播mcast-m查找組播連接列表mcastConnectList-m，查出mcast-m內(nèi)所有的連接connect-m-1..connect-m-N，并發(fā)推送msg-1到消息客戶(hù)端sdk-m-1..sdk-m-N；
5. 消息客戶(hù)端sdk-m-o收到msg-1后，遞交給上層業(yè)務(wù)（例如直播sdk）。

1. 組播mcast的路由維護(hù)，主要壓力在于mcastJoin和mcastLeave，而Join的量級(jí)峰值請(qǐng)求很難超過(guò)2萬(wàn)qps；訪(fǎng)問(wèn)壓力比百萬(wàn)低兩個(gè)數(shù)量級(jí)。
2. 組播mcast的消息推送流程，在一級(jí)路由mcastRoute拆分到長(zhǎng)連接實(shí)例時(shí)，一般在幾十到百量級(jí)，成本很低。
3. 組播mcast在長(zhǎng)連接單實(shí)例內(nèi)的消息推送，是單進(jìn)程內(nèi)的多連接并發(fā)發(fā)送，經(jīng)優(yōu)化后線(xiàn)上實(shí)測(cè)，在單實(shí)例保持25W長(zhǎng)連接的情況下，單實(shí)例壓測(cè)可達(dá)8Wqps的mcast穩(wěn)定下發(fā)，保守按5Wqps容量評(píng)估；多個(gè)長(zhǎng)連接實(shí)例間，是完全的并發(fā)，可以較容易的水平擴(kuò)容。
4. 綜上可知，對(duì)于100Wqps的下發(fā)，20個(gè)長(zhǎng)連接實(shí)例就可以完全負(fù)荷(20*5W=100W)，且有一定裕量。如果500Wqps的下發(fā)，也不超過(guò)100實(shí)例；1000W的下發(fā)，如果以8W單實(shí)例較大的負(fù)荷承載，125實(shí)例就可以支持。
   

2.4.7.1 延時(shí)聚合

• 壓縮

• 限速

• 優(yōu)先級(jí)

• 訪(fǎng)問(wèn)點(diǎn)

• HTTPDNS

• 心跳優(yōu)化

• 斷鏈恢復(fù)

1. 消息服務(wù)和路由層壓力較輕，整體壓力只由長(zhǎng)連接層承載，易于水平擴(kuò)容。
2. 基于延時(shí)聚合下發(fā)，輔以壓縮限速，可以很好的解決下行QPS與帶寬的性能問(wèn)題。
3. 系統(tǒng)整體下行的QPS和帶寬是完全可控的。100W在線(xiàn)用戶(hù)的下行最大QPS是100W，500W在線(xiàn)用戶(hù)的下行最大QPS是500W。單實(shí)例的下發(fā)能力5-8萬(wàn)QPS是穩(wěn)定的。因此，可以很容易判斷整體的系統(tǒng)容量，特殊場(chǎng)景是否需要擴(kuò)容。
4. mcast機(jī)制雖然是針對(duì)直播場(chǎng)景提出的，但本身設(shè)計(jì)具有通用性，可以應(yīng)用于其他需要實(shí)時(shí)在線(xiàn)大量用戶(hù)分組的消息推送場(chǎng)景。