GatewayWorker 中,向一个 uid 发送会涉及到所有 Gateway?

0

看了一下源码,无论是向单个 uid,向群组还是向全部,都会向所有的 gateway 进程发送消息,如果是单个或者群组,每个 gateway 自己寻找当前进程中是否有指定用户的连接,然后向这个链接发送消息。


这样的话,假定连接数非常多,gateway 进程也很多,比如有 1000 个 gateway 进程,那每次向指定的一个人发送都会向这 1000 个进程发一次消息,然后只有其中一个进程会向用户发数据,而其它999个进程检查当前进程没有此连接后忽略,也就是说 BusinessWorker 进程发到 Gateway 的数据中,有999份是浪费无用的,只有1份是正常的。


这种做法感觉有很大的性能和内部流量浪费,有没有什么办法能改进 GatewayWorker 让向指定的某些用户发消息时能具体定位到指定的 gateway 进程,而不是向其它无关的进程都发送呢?


假如这个服务全球七十多亿人,假定一个进程能维护10万的连接,也要7千个进程,那向一个人发送消息,就会导致 6999 个浪费,多么可怕。。。。

已邀请:

walkor

赞同来自:

如果是1000个gateway进程,说明是一个比较繁忙的系统了。
用sendToUid是会有浪费,可以自己做绑定,方法类似如下


新的bindUid内部机制改为 将uid和client_id的映射关系存储起来(redis集群等都可以)。
新的sendToUid机制改为 把uid对应的client_id取出来,然后Gateway::sendToAll发送,不会有任何的通讯浪费。


不过99.9%的业务没有1000个进程那么大的量,更不用说七十多亿人了。
目前的GatewayWorker能满足绝大多数业务场景的量级了,不用考虑这些。


另外手册有建议gatewaway进程数和cpu核数想等,所以gateway进程数不会很多,每个cpu处理一个gateway进程,还是小菜一碟。


其实gatewayWorker瓶颈不是这里,而是当有大量广播或者群租发送时,产生的巨大流量,可以轻松把网卡打满,所以当用户量很大时,需要考虑如何避免频繁的广播或者群组发送。

pader - phper

赞同来自:

那假如这么多个进程都去连 redis 集群,在消息有可能传递给任何人的情况下,进程与 redis 之间的连接数有没有可能成为瓶颈呢。。

walkor

赞同来自:

redis可以分布式部署的,没有瓶颈

pader - phper

赞同来自:

加入 GlobalData 组件,看 GlobalData\Client 好像也是支持分布式的。

pader - phper

赞同来自:

首页 GatewayWorker 下面列表的下载源代码链接错误,指向 Channel 了

walkor

赞同来自:

感谢反馈,已经修复。

要回复问题请先登录注册