聊天应用后端架构？

Question

我正在考虑聊天应用程序后端架构的两种替代方案：

• 每个房间的服务器：用户连接到同一服务器，该服务器直接转发消息和其他事件。数据库用于持久化。
  • 优点：消息传递更快、更高效、涉及的服务器更少
• 每个用户的服务器：每个用户连接到一个服务器，该服务器通过消息代理（即 Redis）将消息和其他事件转发到其他服务器，再由其他服务器将这些事件转发给用户。同样，数据库用于持久性。
  • 优点：架构简单，用户连接到单个服务器，更可靠

注意：术语“服务器”不是指物理机器，而是指特定的地址/端口。

每种模型还有哪些其他优点和缺点？在什么情况下我会使用哪种模型？还有其他可能的后端架构吗？

如果这是相关的：该应用程序侧重于 2 个用户房间（即直接消息传递），不太重视团体或非常大的房间。

如果这不是正确的 Stack Exchange 网络，请告诉我，我可以转移问题。谢谢你！

Answer 1

这里我想向您指出一些事情：

• 构建一个消息应用程序，我假设您将使用 Websocket 来发送和接收消息，这意味着您将需要粘性会话，这也意味着用户每次使用该应用程序时都可能连接到单个服务器
• 您肯定也需要一个消息代理。因为如果没有一个，让所有服务器相​​互通信将是非常痛苦的。Redis 在这里是一个不错的选择，您也可以使用它来缓存用户会话（比数据库更快），但仍然需要持久化到数据库
• 每个用户/房间都有自己的“服务器”（地址/端口）的想法很奇怪。为什么需要这个？从我的角度来看，这非常复杂。您需要：将用户/房间定向到其专用端口，如何知道其专用端口，如何为每个服务器拥有多个地址？...