聊天应用程序后端架构？

Question

我正在考虑聊天应用程序后端架构的两种选择：

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

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

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

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

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

Answer 1

我想为你指出一些事情：

• 构建消息传递应用程序，我假设您将使用Websocket发送和接收消息，这意味着您将需要粘性会话，这也意味着用户每次使用该应用程序时都可能连接到单个服务器
• 你肯定也需要一个消息代理。因为没有一个，让所有服务器与彼此进行通信会非常痛苦。 Redis在这里是个不错的选择，你也可以使用它来缓存用户会话（比db快），但仍需要持久保存到db
• 每个用户/房间的想法得到他们自己的＆＃34;服务器＆＃34; （地址/端口）很奇怪。你为什么需要这个？从我的POV来看，它非常复杂。您需要：将用户/房间指向他们的专用端口，如何知道他们的专用端口，如何为每个服务器提供多个地址？ ...

Answer 2

我想知道为什么要为每个房间（或者你称之为服务器）创建不同的地址和端口的原因

例如，它可以像发布者/订阅者模式一样工作。在单个服务器和单个地址上，创建一个频道，用户（在单个或群组会话中）可以收听该频道。然后，如果用户在该频道上发布消息，您可以将其发送给所有订阅者。

还有不同的方法来处理消息持久性，例如首先将它们插入数据库然后将它们发布到通道中。但正如@Khang指出的那样，需要经纪人。您的代理可能本身可以处理消息持久性，也可以只将消息从一个服务器发送到另一个服务器。 （例如Nats）

另一件事是，如果你想扩展它，你的消息应该能够通过你的分布式网络传播，就像通道用户连接到不同服务器的情况一样;您选择的经纪人仍可以帮助您。

但回到利弊，你谈到的两个解决方案可能会让你在太多地址上打开太多端口（如果我理解正确的话）这似乎没有问题，因为你可能会用完它们而单个端口可以处理您需要的一切。目前我也不知道你将如何实现它。它可能没有比其他架构更快的速度。