Bri*_*asa 19 scalability real-time amazon-sqs amazon-web-services redis
我正在努力想出在AWS中扩展聊天服务的最佳解决方案.我想出了几个潜在的解决方案:
Redis Pub/Sub - 当用户与服务器建立连接时,服务器订阅该用户的ID.当有人向该用户发送消息时,服务器将使用用户的id对该频道执行发布.用户连接的服务器将接收消息并将其下推到相应的客户端.
SQS - 我想过为每个用户创建一个队列.用户连接的服务器将轮询(或使用SQS长轮询)该队列.发现新消息时,它将从服务器推送给用户.
SNS - 我真的很喜欢这个解决方案,直到我发现100个主题限制.我需要为每个用户创建一个主题,该主题仅支持100个用户.
他们可以使用AWS扩展聊天的其他方式吗？SQS方法是否可行？AWS向队列添加消息需要多长时间？
Chr*_* M. 10
建立聊天服务并不像您想象的那么容易.
我已经构建了完整的XMPP服务器,客户端和SDK,并且可以证明出现的一些微妙和困难的问题.用户看到对方和聊天的原型很容易.具有帐户创建,安全性,发现,在线状态,离线交付和朋友列表的完整功能系统更具挑战性.然后,在任意数量的服务器上进行扩展尤其困难.
PubSub是聊天服务(参见XEP-60)提供的功能,而不是构建聊天服务的传统方式.我可以看到诱惑力,但PubSub可能有缺点.
有些问题:1.你是通过网络做的吗？用户是要连接还是长轮询,还是有Web套接字解决方案？
有多少用户？每个用户有多少个连接？写入与读取的比率？
您以这种方式使用SQS的想法很有趣,但可能无法扩展.在聊天服务器上拥有50k或更多用户并不罕见.如果您正在为每个用户轮询每个SQS队列,那么您将无法接近该用户.最好为每个服务器设置一个队列,服务器只轮询该队列.然后,您可以找出用户所在的服务器并将消息放入正确的队列中.
我怀疑你会想要像:
要了解构建聊天服务器的复杂性,请阅读XMPP RFC: RFC 3920 RFC 3921
小智 9
SQS/SNS可能不符合您的健谈要求.我们在SQS中观察到一些可能不适合聊天应用程序的延迟.SQS也不保证FIFO.我在AWS上与Redis合作过.如果配置时考虑到所有最佳实践,它将非常简单和稳定.
HI 实时聊天不能很好地与 SNS 配合使用。它专为电子邮件/短信或服务而设计，1 秒或几秒的延迟是可以接受的。在实时聊天中，1秒或几秒是不可接受的。
\n\n\n\nLatency (i.e. \xe2\x80\x9cRealtime\xe2\x80\x9d) for PubNub vs SNS\nAmazon SNS 不提供延迟保证，并且绝大多数延迟的测量时间都超过 1 秒，而且通常要慢很多秒。再说一遍，这有点无关紧要。Amazon SNS 专为服务器到服务器（或电子邮件/SMS）通知而设计，其中数秒的延迟通常是可以接受和预期的。
\n\n由于 PubNub 通过现有的、已建立的开放网络套接字传递数据，因此在 95% 的订阅设备中，从发布到订阅的延迟低于 0.25 秒。如果事件在 0.6 \xe2\x80\x93 0.7 秒内被感知，大多数人将其感知为 \xe2\x80\x9crealtime\xe2\x80\x9d。
\n