Socket.io & Redis - io 游戏的正确架构？

Question

我正在使用带有Redis架构的基本NodeJS缩放，但我无法将其配置为适合实时多人游戏。

我的多人游戏应该有单独的大厅 - 所以当负载平衡器将用户放置在单独的服务器中时，同一个大厅中的玩家无法交流，除非我使用Redis 。 问题是，我不能在服务器之间来回发送每一个动作，因为这会超载Redis ，并破坏服务器实例的可扩展性，因为现在我必须将每个用户存储在每个 NodeJS 实例中（检查碰撞等），这违背了缩放的目的。 除非我做错了什么？

基本 NodeJS/Redis 架构（对于带有大厅的 io 游戏效率低下？）

我还添加了一个单独的运行管理器，它配置（创建/删除大厅）大厅，并通过 Redis 将信息发送到 Worker 实例，以便用户查看可用的大厅

我曾想过让每个 NodeJS 实例成为一个单独的大厅，但负载均衡器不能那样工作。 此外，没有自动缩放。

我目前的架构，展示玩家（用户）

Red代表用户

Light Pink适用于通过 Redis 从其他服务器到自身的同步用户（否则，来自其他实例的玩家将彼此不可见。此外，将无法执行简单的更新，例如碰撞检测）

每个玩家都在自己选择的lobby ，并且是一个 object 拥有X ， Y ， angle和其他几个参数

即使用户会加入Worker 2或Worker 'n' ，我仍然需要将用户配置文件转发给其他工作人员，否则不在同一个Worker上的用户将彼此不可见。 现在在这种情况下，它不是完全违背了缩放的目的吗？

要么我做错了什么，要么我确信必须有一个解决方案！

编辑

到目前为止，这是我自己想出的，尽管不确定是否合理

我几乎没有得到任何帮助，一些评论将不胜感激

Answer 1

发表评论作为答案

根据评论，游戏是在团队之间进行的，每个团队都有一些成员，但游戏中的每个成员都必须了解其他成员（不仅是他们的团队成员），因为每个成员都必须了解游戏中的所有其他成员， go 用这种设计很好。

虽然隔离应该在游戏级别进行，但每个游戏都应该有自己的一组大厅，每个大厅都包含所有玩家。

我们不必为每个大厅运行工作人员，而是可以为一个游戏使用一个工作人员，这将更新所有大厅数据。

此外，不应使用负载均衡器在工作人员之间分配玩家，而应在应用程序中使用中间件，如 GamePlayerManager/LobbyPlayerManager 来将玩家添加到特定大厅/从特定大厅中移除玩家。