gatewayworker的gateway类处理worker的消息量上限问题

zz_rw

gatewayworker里 businessworker发给gateway的消息,比如群发消息,是通过轮询每个gateway进程的方式发送消息。这种情况下如果群发消息比较频繁的话,如果单台网关处理能力不足的情况下(目前测的结果是每核CPU处理的上限在2.5w/s左右,如果群发消息并发量超过2.5w),横向扩容网关没法解决这个问题,不知道大神们有什么建议吗???

2204 2 0
2个回答

华哥

有那么大的消息量吗? 我们现在前端 每秒 100条数据发数据,导致全部堆积到 socket 里 , 基本上延时 1-2给小时才能下发完, 到现在也不清楚原因原因,现在发现 后端处理只能处理 每秒10条数据?

  • q13113671764 2020-09-10

    一秒只能发10条消息,问题肯定出在自己那,不可能每秒只能处理10条的

walkor 打赏

鸟哥微博说过,微博春节零时QPS不过数万。如果你群发的QPS超过2.5万,应该也是和微博差不多一个量级的应用了。
如果是这个量级的话,不能指望简单的GatewayWorker分布式就能解决,如果是那样,鸟哥就找不到工作了(坏笑)。

言归正传,gatewayWorker之所以群发的时候无差别将消息发给所有gateway服务,是因为gatewayWorker没办法确认对应群组id在哪个gateway服务器上(或进程上)。如果新的服务架构可以解决这个问题,那么单机QPS瓶颈限制系统并发瓶颈的问题就解决了。

最简单的方法将将服务器按群组划分,特定服务器只处理特定分组的连接。比如10台群组服务器,客户端根据当前用户有哪些群组,按照 群组id 取模 的算法去连特定的群服务器。这样给某个群发消息,只需要给特定那台服务器发信息通讯即可。原来2.5WQPS的工作瞬间降到2.5K QPS。如果觉得还不够,可以设置100台群组服务器变成250 QPS。

这样带来另外一个问题,如果这个人比较活跃有很多群组,最坏的情况,客户端要与所有群服务器都保持一个连接。解决这个问题的方法也很简单,在群服务器前加一层代理服务器,客户端只连代理服务器,代理服务器根据客户端情况去连群服务器。

整体服务架构类似这样。

[群服务器1] [群服务器2] [群服务器3] ...
    |       /
    |    /
[代理服务器1] [代理服务器2] [代理服务器3] ...
    |
  [客户端]

当然,这个已经不是GatewayWorker服务器架构了,是一个专用群发服务器架构,用workerman很容易实现。

  • 暂无评论
年代过于久远,无法发表回答
×
🔝