amazon-web-services - 在 AWS 中扩展聊天的想法？

Question

我正在努力想出在 AWS 中扩展聊天服务的最佳解决方案。我想出了几个可能的解决方案:

1. Redis Pub/Sub - 当用户建立到服务器的连接时，服务器会订阅该用户的 ID。当有人向该用户发送消息时，服务器将使用该用户的 ID 执行发布到 channel 。用户连接的服务器将接收消息并将其向下推送到适当的客户端。

2. SQS - 我考虑过为每个用户创建一个队列。用户连接的服务器将轮询(或使用 SQS 长轮询)该队列。当发现新消息时，它会从服务器推送给用户。

3. SNS - 在发现 100 个主题限制之前，我真的很喜欢这个解决方案。我需要为每个用户创建一个主题，它只支持 100 个用户。

是否有任何其他方式可以使用 AWS 扩展聊天？ SQS 方法是否可行？ AWS 将消息添加到队列需要多长时间？

Answer 1

构建聊天服务并不像您想象的那么容易。

我已经构建了完整的 XMPP服务器、客户端和 SDK，并且可以证明出现的一些微妙和困难的问题。用户可以轻松看到彼此并聊天的原型(prototype)。具有帐户创建、安全性、发现、存在、离线交付和 friend 列表的全功能系统更具挑战性。然后在任意数量的服务器上扩展它特别困难。

PubSub 是聊天服务 (see XEP-60) 提供的一项功能，而不是构建聊天服务的传统方式。我可以看到诱惑，但 PubSub 也有缺点。

一些问题:

1. 您是通过网络执行此操作的吗？用户是要进行连接和长轮询，还是您有 Web Sockets 解决方案？

2. 有多少用户？每个用户有多少个连接？写入与读取的比率？

3. 您以这种方式使用 SQS 的想法很有趣，但可能无法扩展。聊天服务器上有 5 万或更多用户并不罕见。如果您为每个用户轮询每个 SQS 队列，您将无法接近它。您最好为每个服务器设置一个队列，并且服务器只轮询该队列。然后由您来确定用户所在的服务器并将消息放入正确的队列中。

我猜你会想做这样的事:

1. 后端有一个大型 RDS 数据库。
2. 一组处理客户端连接的前端服务器。
3. 一些中间层 Java/C# 代码跟踪一切并将消息路由到正确的位置。

要了解构建聊天服务器的复杂性，请阅读 XMPP RFC: RFC 3920 RFC 3921