我试图想出在AWS中扩展聊天服务的最佳解决方案。我想出了几个可能的解决方案：在AWS中扩展聊天的想法？
的Redis的Pub/Sub - 当用户建立至该服务器预订该用户的ID服务器的连接。当有人向该用户发送消息时，服务器将使用该用户的ID执行发布到该频道。用户所连接的服务器将收到该消息并将其推送到适当的客户端。
SQS - 我想为每个用户创建一个队列。用户连接的服务器将轮询（或使用SQS长轮询）该队列。当发现新消息时，它将从服务器推送给用户。
SNS - 我真的很喜欢这个解决方案，直到我发现了100个主题的限制。我需要为每个用户创建一个主题，该主题仅支持100个用户。
是否有任何其他方式可以使用AWS扩展聊天？ SQS方法是否可行？ AWS需要多长时间才能将消息添加到队列中？
构建聊天服务并不像您想象的那么容易。
我已经构建了完整的XMPP服务器，客户端和SDK，可以证明出现的一些微妙和困难的问题。用户互相看到并且聊天很容易的原型。具有账户创建，安全性，发现，在线状态，离线传送和好友列表的完整功能系统更具挑战性。然后在任意数量的服务器上进行扩展尤其困难。
PubSub是聊天服务（see XEP-60）提供的一项功能，而不是传统的构建聊天服务的方式。我可以看到魅力，但是PubSub可能有缺点。
对你有一些问题： 1.你在网上做这个吗？用户是否会连接并长时间连接，或者您是否拥有Web套接字解决方案？
有多少用户？每个用户有多少个连接？写入与读取的比率？
您对这种使用SQS的想法很有趣，但可能无法扩展。在聊天服务器上拥有5万以上的用户并不少见。如果您正在为每个用户轮询每个SQS队列，那么您将无法在其附近获得任何附加信息。为每个服务器设置一个队列会更好，并且服务器仅轮询该队列。然后找出用户所在的服务器并将其放入正确的队列中。
我怀疑你会想要去是这样的：
我想实现这样的事情（如果不使用某些框架）的方法如下：
有一个web服务器（在ec2上）接受来自用户的信息。 在此Web服务器上使用Autoscalling组。网络服务器可以更新amazon RDS上的任何可轻松扩展的数据库。
如果你使用自己的数据库，你可能会考虑使用sqs（通过发送所有请求相同的队列）将数据库从web服务器上解耦，然后你可以让消费者使用队列。这个消费者也可以放在一个自动调整组的后面，这样如果队列大于X个消息，它将按比例调整（你可以设置报警）
sqs正常更新很快，即少于一秒。 （从发送它的那一刻起，直到它出现在队列中的那一刻），并且很少超过这个时间。
SQS/SNS可能不适合您的健谈要求。我们观察到SQS中的某些延迟可能不适用于聊天应用程序。 SQS也不保证FIFO。我在AWS上使用Redis。如果配置考虑了所有最佳实践，则它非常简单且稳定。
SQS现在支持FIFO que，更多信息在我的答案中。感谢您在此之前指出它。 – Kainax 2016-11-25 15:42:04
我想过构建使用SNS聊天服务器，但是在做每个用户一个话题，你形容，做整个聊天系统一个主题，让每个服务器订阅主题 - 每个服务器运行某种长轮询或Web套接字聊天系统。然后，当事件发生时，数据在SNS通知的有效载荷中发送。然后，服务器可以使用该有效负载来确定队列中的哪些客户端应该接收到响应，从而保持任何不相关的客户端不变。实际上，我为此构建了一个小型原型，但并没有进行大量测试，以确定它是否足够适用于大量用户。
以来的新AWS服务的IoT开始支持WebSockets的，保持连接和发布/订阅几个月前，你可以很容易地在其上建立弹性聊天。 AWS IoT是一项托管服务，其中包含针对不同语言的大量SDK，包括用于处理零管理的怪物负载（数十亿条消息）的JavaScript。
你可以阅读更多关于更新这里：
编辑：
最后SQS更新（一十一分之二千○一十六）：你现在可以使用亚马逊简单队列服务（SQS）对于需要按严格顺序处理消息的应用程序以及使用先进先出（FIFO）队列的应用程序。 FIFO队列旨在确保严格保持消息发送和接收的顺序，并确保每条消息只处理一次。
现在开始，实施SQS + SNS看起来像一个好主意了。
HI实时聊天不适合SNS。它专为电子邮件/短信或服务1或几秒钟延迟是可以接受的。在实时聊天中，1或几秒钟是而不是可以接受。
Latency (i.e. “Realtime”) for PubNub vs SNS
亚马逊SNS不提供延迟保证，且绝大多数延迟都超过1秒测量，并且经常是许多秒慢。再次，这有点不相关; Amazon SNS专为服务器到服务器（或电子邮件/ SMS）通知而设计，其中延迟时间通常可以接受和预期。
因为PubNub通过现有的已建立的开放式网络套接字提供数据，所以从发布到订阅订阅设备的95％的百分比时，延迟时间小于0.25秒。如果在0.6-0.7秒内感知到事件，则大多数人认为某事物是“实时”的。
感谢这个答案，很多很棒的信息！聊天服务将通过网络建立。目前的想法是使用简单的长轮询解决方案将消息推送到浏览器。就用户数而言，它是一款新产品，所以我们没有一个好的评估。我们希望能够支持注册的许多用户。你对SQS的想法很有趣，我对SQS的主要关注点是消息之间的延迟。如果一个用户向队列中添加消息，接收该消息需要多长时间？可能是我需要做一个原型的东西。 – 2013-05-09 14:37:18
公平点，但该设置（关系数据库，硬件绑定的缩放，以及用于控制的Java/C＃）看起来像是一种“老派”的聊天方式。现在，我会研究平面文件的长期存储（可能会将最新消息每分钟转储到S3一次？），Pub/Sub的SNS（每个“房间”有一个主题），一组高性能非像Twisted（Python）或Node.js（JavaScript）这样的线程化事件服务器，最后是Web Sockets和/或Server Sent Events，以在服务器上实现尽可能轻的负载，同时保持消息流对每个客户端都有效。或者我错过了什么？ – 2014-01-22 20:02:27
@Roland。我同意你的看法，背后的大型关系数据库和一大堆前端服务器就是这样做的老派方式。如果我今天建立了一项服务，我可能会使用RDS和DynamoDB的组合。使用网络套接字或长轮询的前端将取决于我们所针对的客户端类型。有很多方法可以对这只猫进行剥皮，并且在不知道相关要求的情况下（在私有局域网上运行？在云中？扩展？成本问题？增长率？客户类型？数据生命周期等），很难说更多... – 2014-01-23 21:29:23