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

0

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

已邀请:

华哥

赞同来自:

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

要回复问题请先登录注册