GatewayWorker 中，向一个 uid 发送会涉及到所有 Gateway？
看了一下源码，无论是向单个 uid，向群组还是向全部，都会向所有的 gateway 进程发送消息，如果是单个或者群组，每个 gateway 自己寻找当前进程中是否有指定用户的连接，然后向这个链接发送消息。
这样的话，假定连接数非常多，gateway 进程也很多，比如有 1000 个 gateway 进程，那每次向指定的一个人发送都会向这 1000 个进程发一次消息，然后只有其中一个进程会向用户发数据，而其它999个进程检查当前进程没有此连接后忽略，也就是说 BusinessWorker 进程发到 Gateway 的数据中，有999份是浪费无用的，只有1份是正常的。
这种做法感觉有很大的性能和内部流量浪费，有没有什么办法能改进 GatewayWorker 让向指定的某些用户发消息时能具体定位到指定的 gateway 进程，而不是向其它无关的进程都发送呢？
假如这个服务全球七十多亿人，假定一个进程能维护10万的连接，也要7千个进程，那向一个人发送消息，就会导致 6999 个浪费，多么可怕。。。。
3402 6 0
6个回答
相似问题
年代过于久远，无法发表回答
如果是1000个gateway进程，说明是一个比较繁忙的系统了。
用sendToUid是会有浪费，可以自己做绑定，方法类似如下
新的bindUid内部机制改为 将uid和client_id的映射关系存储起来(redis集群等都可以)。
新的sendToUid机制改为 把uid对应的client_id取出来，然后Gateway::sendToAll发送，不会有任何的通讯浪费。
不过99.9%的业务没有1000个进程那么大的量，更不用说七十多亿人了。
目前的GatewayWorker能满足绝大多数业务场景的量级了，不用考虑这些。
另外手册有建议gatewaway进程数和cpu核数想等，所以gateway进程数不会很多，每个cpu处理一个gateway进程，还是小菜一碟。
其实gatewayWorker瓶颈不是这里，而是当有大量广播或者群租发送时，产生的巨大流量，可以轻松把网卡打满，所以当用户量很大时，需要考虑如何避免频繁的广播或者群组发送。
那假如这么多个进程都去连 redis 集群，在消息有可能传递给任何人的情况下，进程与 redis 之间的连接数有没有可能成为瓶颈呢。。
redis可以分布式部署的，没有瓶颈
加入 GlobalData 组件，看 GlobalData\Client 好像也是支持分布式的。
首页 GatewayWorker 下面列表的下载源代码链接错误，指向 Channel 了
感谢反馈，已经修复。