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