有那么大的消息量嗎？ 我們現(xiàn)在前端 每秒 100條數(shù)據(jù)發(fā)數(shù)據(jù)，導(dǎo)致全部堆積到 socket 里 ， 基本上延時 1-2給小時才能下發(fā)完， 到現(xiàn)在也不清楚原因原因，現(xiàn)在發(fā)現(xiàn) 后端處理只能處理 每秒10條數(shù)據(jù)？

鳥哥微博說過，微博春節(jié)零時QPS不過數(shù)萬。如果你群發(fā)的QPS超過2.5萬，應(yīng)該也是和微博差不多一個量級的應(yīng)用了。
如果是這個量級的話，不能指望簡單的GatewayWorker分布式就能解決，如果是那樣，鳥哥就找不到工作了(壞笑)。

言歸正傳，gatewayWorker之所以群發(fā)的時候無差別將消息發(fā)給所有g(shù)ateway服務(wù)，是因為gatewayWorker沒辦法確認對應(yīng)群組id在哪個gateway服務(wù)器上(或進程上)。如果新的服務(wù)架構(gòu)可以解決這個問題，那么單機QPS瓶頸限制系統(tǒng)并發(fā)瓶頸的問題就解決了。

最簡單的方法將將服務(wù)器按群組劃分，特定服務(wù)器只處理特定分組的連接。比如10臺群組服務(wù)器，客戶端根據(jù)當前用戶有哪些群組，按照 群組id 取模 的算法去連特定的群服務(wù)器。這樣給某個群發(fā)消息，只需要給特定那臺服務(wù)器發(fā)信息通訊即可。原來2.5WQPS的工作瞬間降到2.5K QPS。如果覺得還不夠，可以設(shè)置100臺群組服務(wù)器變成250 QPS。

這樣帶來另外一個問題，如果這個人比較活躍有很多群組，最壞的情況，客戶端要與所有群服務(wù)器都保持一個連接。解決這個問題的方法也很簡單，在群服務(wù)器前加一層代理服務(wù)器，客戶端只連代理服務(wù)器，代理服務(wù)器根據(jù)客戶端情況去連群服務(wù)器。

整體服務(wù)架構(gòu)類似這樣。

[群服務(wù)器1] [群服務(wù)器2] [群服務(wù)器3] ...
    |       /
    |    /
[代理服務(wù)器1] [代理服務(wù)器2] [代理服務(wù)器3] ...
    |
  [客戶端]

當然，這個已經(jīng)不是GatewayWorker服務(wù)器架構(gòu)了，是一個專用群發(fā)服務(wù)器架構(gòu)，用workerman很容易實現(xiàn)。