server - 聊天应用后端架构？

Question

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

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

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

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

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

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

Answer 1

我想向您指出一些事情:

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