amazon-web-services - Amazon SQS 队列限制

Question

我的项目需要我与云之外的许多设备进行通信。如果成功，这意味着数以百万计的设备。这些设备不会运行 Android 或 iOS，而是在路由器和防火墙后面运行(我不能假设它们有外部 IP)。

我希望使用 SQS 向云外的用户发送消息。为了允许服务器向单个用户发送消息，我将系统设计为每个客户端有一个队列。这可能意味着数百万(数十亿？)个队列。虽然它声明 SQS 可以支持无限队列，但我想确保我没有滥用系统。如果成功，百万用户的概率非常高。

我知道 SQS 可能很贵，但我在这个阶段使用它
为了便于管理。

据我所知，SNS 需要一个 IOS/Android 客户端，或者一个
在消费者上运行的 HTTP 服务器。这就是为什么我排除了 SNS，我
我正在使用 SQS。

我将通过 SQS 构建一个分布式云前端来处理
客户端连接。这个前端只是一个包装器，它将
验证客户端，并将它们中继到 SQS 队列。

我是否在滥用 SQS“无限队列”政策(SQS 性能会下降)吗？每个设备的消息传递是否有更简单的设计？

Answer 1

让我按你的问题的部分来打破答案:

关于您的 问题 :

Am I abusing the SQS "unlimited queues" policy?

AWS 服务旨在防止滥用，您将按实际使用量付费，因此如果您认为这是正确的方法，请继续使用。为了消除不确定性，我建议进行初步的“概念证明”实现。

Is there a simpler design for per device messaging?

可能是的，重新考虑 SNS 和其他消息传递系统。

关于您的 声明 :

I am aware that SQS can be expensive, but I am using it at this stage for ease of administration.

考虑到 SQS 消息的成本为 0.00000005 美元，“昂贵”是一种非常依赖于上下文的分类。

As far as I can tell SNS requires either an IOS/Android client, or an HTTP server running on the consumer. This is why I ruled out SNS, and I am using SQS.

SNS 是一个基于推送的消息系统(SQS 是基于拉的)，可以处理 5 种订阅类型:smtp、sms、http、移动推送和 SQS，因此它们并不相互排斥。

I am going to build a distributed cloud front-end over SQS to handle client connections. This front-end will just be a wrapper, that will authenticate clients, and relay them to the SQS queues.

对于“基于 SQS 的分布式云前端”而言，管理数百万个队列可能是一项艰巨的任务。除非您的项目完全是关于队列管理，否则这可能是无差别的繁重工作。

这就是我在不了解您的情况下可以说的全部内容，但请考虑您可以将 SNS/SQS 与彼此以及其他消息传递软件(例如 Apache Camel 等)一起使用，这可能有助于您构建解决方案或概念验证。