在 AWS 中扩展聊天的想法? [英] Ideas for scaling chat in AWS?

问题描述

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

I'm trying to come up with the best solution for scaling a chat service in AWS. I've come up with a couple potential solutions:

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

1. Redis Pub/Sub - When a user establishes a connection to a server that server subscribes to that user's ID. When someone sends a message to that user, a server will perform a publish to the channel with the user's id. The server the user is connected to will receive the message and push it down to the appropriate client.

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

SQS - I've thought of creating a queue for each user. The server the user is connected to will poll (or use SQS long-polling) that queue. When a new message is discovered, it will be pushed to the user from the server.

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

SNS - I really liked this solution until I discovered the 100 topic limit. I would need to create a topic for each user, which would only support 100 users.

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

Are their any other ways chat could be scaled using AWS? Is the SQS approach viable? How long does it take AWS to add a message to a queue?

推荐答案

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

Building a chat service isn't as easy as you would think.

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

I've built full XMPP servers, clients, and SDK's and can attest to some of the subtle and difficult problems that arise. A prototype where users see each other and chat is easy. A full features system with account creation, security, discovery, presence, offline delivery, and friend lists is much more of a challenge. To then scale that across an arbitrary number of servers is especially difficult.

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

PubSub is a feature offered by Chat Services (see XEP-60) rather than a traditional means of building a chat service. I can see the allure, but PubSub can have drawbacks.

一些问题:

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

1. Are you doing this over the Web? Are users going to be connecting and long-poling or do you have a Web Sockets solution?

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

How many users? How many connections per user? Ratio of writes to reads?

您以这种方式使用 SQS 的想法很有趣，但可能无法扩展.在聊天服务器上拥有 50k 或更多用户并不罕见.如果您为每个用户轮询每个 SQS 队列，您将无法获得任何结果.您最好为每个服务器设置一个队列，并且服务器仅轮询该队列.然后由您来确定用户在哪个服务器上并将消息放入正确的队列中.

Your idea for using SQS that way is interesting, but probably won't scale. It's not unusual to have 50k or more users on a chat server. If you're polling each SQS Queue for each user you're not going to get anywhere near that. You would be better off having a queue for each server, and the server polls only that queue. Then it's on you to figure out what server a user is on and put the message into the right queue.

我怀疑你会想要:

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

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

To get an idea of the complexity of building a chat server read the XMPP RFC's: RFC 3920 RFC 3921

这篇关于在 AWS 中扩展聊天的想法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！