邏輯層廣播到網(wǎng)管層會(huì)不會(huì)太浪費(fèi)資源了呢
上一節(jié)課，不是說可以維護(hù)，用戶連接，房間一個(gè)映射關(guān)系嗎，通過這個(gè)映射關(guān)系推送到指定的網(wǎng)管層，與直接廣播到所有的網(wǎng)管節(jié)點(diǎn)有啥利弊呢
3 回答
舉報(bào)
0/150
提交
取消
上一節(jié)課，不是說可以維護(hù)，用戶連接，房間一個(gè)映射關(guān)系嗎，通過這個(gè)映射關(guān)系推送到指定的網(wǎng)管層，與直接廣播到所有的網(wǎng)管節(jié)點(diǎn)有啥利弊呢
舉報(bào)
2018-08-01
前置前置再前置，把合并越推向原點(diǎn)，對(duì)系統(tǒng)整體優(yōu)化效果更佳，掌握這一點(diǎn)即可！
2018-08-01
字?jǐn)?shù)限制。
實(shí)際上內(nèi)部通訊也需要合并推送，這個(gè)出于簡化原因我沒有實(shí)現(xiàn)在開源代碼里。 所有的無狀態(tài)logic應(yīng)該按room推送消息到消息隊(duì)列（按room分區(qū)），然后通過pusher服務(wù)去完成房間粒度的消息合并，并廣播給gateway。
思考架構(gòu)問題需要考慮場(chǎng)景，切忌空談性能，在具體場(chǎng)景下有具體的難點(diǎn)和具體的應(yīng)對(duì)方案，這個(gè)思想很重要。
2018-08-01
嗯，這個(gè)問題很有意思，引申出了這個(gè)分布式系統(tǒng)后續(xù)的一些走向，我簡單延伸一下。
如果是定向給某個(gè)用戶推送，我們一般會(huì)在邏輯服務(wù)器后面設(shè)計(jì)一層session服務(wù)，記錄用戶在哪些gateway上，從而減少不必要的廣播。
如果是定向給某個(gè)房間推送，需要我們主動(dòng)的連接調(diào)度，用戶進(jìn)入房間前先詢問服務(wù)端，由服務(wù)端指派網(wǎng)關(guān)節(jié)點(diǎn)地址，這樣盡量來把同一個(gè)房間的用戶聚集在一起，你可以想一下增加這個(gè)特性的性價(jià)比有多少。
我覺得在彈幕場(chǎng)景里，內(nèi)部節(jié)點(diǎn)之間的廣播消息量并不是瓶頸（特指內(nèi)網(wǎng)帶寬瓶頸），因?yàn)?00萬人*10個(gè)網(wǎng)關(guān)在線，你推送1條彈幕的瓶頸永遠(yuǎn)在網(wǎng)關(guān)層。
所以，在考慮生產(chǎn)環(huán)境的擴(kuò)展性架構(gòu)決策時(shí)，gateway+logic應(yīng)該作為一個(gè)服務(wù)單元（我們也稱為set），通過部署多套set來實(shí)現(xiàn)大規(guī)模集群部署，具體一個(gè)房間只需要調(diào)度到某個(gè)set即可保障其高可用和高吞吐。