在AWS中扩展聊天的想法？

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

Redis Pub/Sub - 当用户与服务器建立连接时,服务器订阅该用户的ID.当有人向该用户发送消息时,服务器将使用用户的id对该频道执行发布.用户连接的服务器将接收消息并将其下推到相应的客户端.

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

SNS - 我真的很喜欢这个解决方案,直到我发现100个主题限制.我需要为每个用户创建一个主题,该主题仅支持100个用户.

他们可以使用AWS扩展聊天的其他方式吗？SQS方法是否可行？AWS向队列添加消息需要多长时间？

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

我已经构建了完整的XMPP服务器,客户端和SDK,并且可以证明出现的一些微妙和困难的问题.用户看到对方和聊天的原型很容易.具有帐户创建,安全性,发现,在线状态,离线交付和朋友列表的完整功能系统更具挑战性.然后,在任意数量的服务器上进行扩展尤其困难.

PubSub是聊天服务(参见XEP-60)提供的功能,而不是构建聊天服务的传统方式.我可以看到诱惑力,但PubSub可能有缺点.

有些问题:1.你是通过网络做的吗？用户是要连接还是长轮询,还是有Web套接字解决方案？

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

您以这种方式使用SQS的想法很有趣,但可能无法扩展.在聊天服务器上拥有50k或更多用户并不罕见.如果您正在为每个用户轮询每个SQS队列,那么您将无法接近该用户.最好为每个服务器设置一个队列,服务器只轮询该队列.然后,您可以找出用户所在的服务器并将消息放入正确的队列中.

我怀疑你会想要像:

后端的大型RDS数据库.

一堆处理客户端连接的前端服务器.

一些中间层Java/C#代码跟踪所有内容并将消息路由到正确的位置.

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

SQS/SNS可能不符合您的健谈要求.我们在SQS中观察到一些可能不适合聊天应用程序的延迟.SQS也不保证FIFO.我在AWS上与Redis合作过.如果配置时考虑到所有最佳实践,它将非常简单和稳定.