我正在努力想出在AWS中扩展聊天服务的最佳解决方案。我想出了几个可能的解决方案：
Redis Pub / Sub - 当用户与服务器建立连接时，服务器订阅该用户的ID。当有人向该用户发送消息时，服务器将使用用户的id对该频道执行发布。用户连接的服务器将接收消息并将其下推到相应的客户端。
SQS - 我想过为每个用户创建一个队列。用户连接的服务器将轮询（或使用SQS长轮询）该队列。当发现新消息时，它将从服务器推送给用户。
SNS - 我真的很喜欢这个解决方案，直到我发现100个主题限制。我需要为每个用户创建一个主题，该主题只能支持100个用户。
他们可以通过AWS扩展聊天的其他方式吗？ SQS方法是否可行？ AWS将消息添加到队列需要多长时间？
答案 0 :(得分：10)
构建聊天服务并不像您想象的那么容易。
我已经构建了完整的XMPP服务器，客户端和SDK，并且可以证明出现的一些微妙和困难的问题。用户看到对方和聊天的原型很容易。具有帐户创建，安全性，发现，在线状态，离线交付和朋友列表的完整功能系统更具挑战性。然后，在任意数量的服务器上进行扩展尤其困难。
PubSub是聊天服务（see XEP-60）提供的功能，而不是传统的构建聊天服务的方式。我可以看到诱惑力，但PubSub可能有缺点。
有些问题要问你： 你是通过网络这样做的吗？用户是要连接还是长轮询，还是有Web套接字解决方案？
答案 1 :(得分：9)
SQS / SNS可能不适合您的健谈要求。我们在SQS中观察到一些可能不适合聊天应用程序的延迟。 SQS也不保证FIFO。我在AWS上与Redis合作过。如果配置时考虑到所有最佳实践，那么它非常容易和稳定。
答案 2 :(得分：4)
我考虑使用SNS构建聊天服务器，但不是像每个用户那样为每个用户做一个主题，而是为整个聊天系统做一个主题并让每个服务器订阅主题 - 每个服务器都在运行某种长轮询或网络套接字聊天系统。然后，当事件发生时，数据在SNS通知的有效载荷中发送。然后，服务器可以使用此有效负载来确定其队列中的哪些客户端应该接收响应，从而保持任何不相关的客户端不变。我实际上为此构建了一个小型原型，但还没有进行大量的测试，看它是否足够强大，适合大量用户。
答案 3 :(得分：3)
HI实时聊天与SNS不兼容。它专为电子邮件/短信或服务设计1或几秒延迟是可以接受的。在实时聊天中，1或几秒不可接受。
Latency (i.e. “Realtime”) for PubNub vs SNS
Amazon SNS不提供延迟保证，绝大多数延迟的测量时间超过1秒，通常慢几秒。再次，这有点无关紧要; Amazon SNS专为服务器到服务器（或电子邮件/ SMS）通知而设计，其中许多秒的延迟通常是可接受的和预期的。
由于PubNub通过现有的已建立的开放式网络套接字提供数据，因此在订阅设备的95％百分比中，从发布到订阅的延迟时间不到0.25秒。如果事件在0.6-0.7秒内被感知，大多数人都认为某些事物是“实时的”。
答案 4 :(得分：2)
我实现这样的事情（如果不使用某个框架）的方式如下：
有一个web服务器（在ec2上），它接受来自用户的消息。 在此网络服务器上使用自动分组。网络服务器可以更新亚马逊RDS上的任何数据库，可以轻松扩展。
如果您使用自己的数据库，您可能会考虑使用sqs将数据库与网络服务器分离（通过将所有请求发送到同一队列），然后您可以让消费者使用该队列。此消费者也可以放在自动调整组后面，这样如果队列大于X个消息，它就会缩放（你可以用警报设置它）
sqs通常会快速更新，但不到一秒钟。 （从你发送它的那一刻起，到它出现在队列中的那一刻），并且很少超过它。
答案 5 :(得分：1)
由于几个月前新的AWS IoT服务开始支持WebSockets，Keepalive和Pub / Sub，您可以轻松地在其上构建弹性聊天。 AWS IoT是一种托管服务，包含许多适用于不同语言的SDK，包括用于处理怪物负载（数十亿条消息）而无需管理的JavaScript。
您可以在此处详细了解更新：
编辑：
上一次SQS更新（2016/11）：您现在可以将Amazon Simple Queue Service（SQS）用于需要按严格顺序处理消息的应用程序，以及使用先进先出（FIFO）队列完成一次的应用程序。 FIFO队列旨在确保严格保留发送和接收消息的顺序，并确保每条消息只处理一次。
现在，实施SQS + SNS看起来也是一个好主意。