GatewayWorker 中，向一个 uid 发送会涉及到所有 Gateway？
看了一下源码，无论是向单个 uid，向群组还是向全部，都会向所有的 gateway 进程发送消息，如果是单个或者群组，每个 gateway 自己寻找当前进程中是否有指定用户的连接，然后向这个链接发送消息。
这样的话，假定连接数非常多，gateway 进程也很多，比如有 1000 个 gateway 进程，那每次向指定的一个人发送都会向这 1000 个进程发一次消息，然后只有其中一个进程会向用户发数据，而其它999个进程检查当前进程没有此连接后忽略，也就是说 BusinessWorker 进程发到 Gateway 的数据中，有999份是浪费无用的，只有1份是正常的。
这种做法感觉有很大的性能和内部流量浪费，有没有什么办法能改进 GatewayWorker 让向指定的某些用户发消息时能具体定位到指定的 gateway 进程，而不是向其它无关的进程都发送呢？
假如这个服务全球七十多亿人，假定一个进程能维护10万的连接，也要7千个进程，那向一个人发送消息，就会导致 6999 个浪费，多么可怕。。。。
3453 6 0
6个回答
相似问题
年代过于久远，无法发表回答
月贡献榜
赞助商
热门问答
workerman 里面的redis 队列是基于redis的什么特性实现的？
redis-queue 延迟队列不消费，使用的官方源码安装
联表一次查询和查询后循环内再查询别的表组装数据，哪个性能好呢？
webman想使用人大金仓数据库，如何处理？ 求方案
PHP8.4下webman直接用topthink/think-orm想了解数据库连接该写在哪里
微信SDK，关于webman里推荐的
redis-queue 延迟任务 可否延迟第二天触发？
/* * 注意这里进程数必须设置为1 */ $worker->count = 1;
是否需要用GatewayWorker来替换PhpSocket.io
请问下现阶段是否有必要使用异步mysql查询？
如果是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 了
感谢反馈，已经修复。