我的项目要求我与云外的许多设备进行通信。如果成功，这意味着数百万台设备。这些设备将不会运行Android或iOS，并将在路由器和运行后面运行。防火墙（我不能假设他们有外部IP）。
我希望使用SQS向云外的用户发送消息。为了允许服务器向单个用户发送消息，我设计的系统是每个客户端有一个队列。这可能意味着数百万（数十亿？）的队列。虽然它声明SQS可以支持无限队列，但我想确保我没有滥用系统。如果成功，数百万用户的概率非常高。
我是否滥用SQS＆＃34;无限排队＆＃34;政策（SQS表现会下降）？每个设备的消息传递是否有更简单的设计？
答案 0 :(得分：3)
让我打破你问题部分的答案：
关于问题：
Am I abusing the SQS "unlimited queues" policy?
AWS服务旨在防止滥用，您将为您使用的内容付费，因此如果您认为这是正确的方法，那就去做吧。为了消除不确定性，我建议初步的“概念证明”实施。
Is there a simpler design for per device messaging?
可能是的，重新考虑SNS和其他消息系统。
关于声明：
我知道SQS可能很昂贵，但我现在正在使用它 为了便于管理。
“昂贵”是一种非常依赖于上下文的分类，考虑到SQS消息的成本为0.00000005美元。
据我所知，SNS需要一个IOS / Android客户端，或者一个 在使用者上运行的HTTP服务器。这就是我排除SNS的原因 我正在使用SQS。
SNS是基于推送的消息系统（SQS是基于拉取的），可以处理5种类型的订阅：smtp，sms，http，移动推送和 SQS，因此它们不是互斥的。< / p>
我将通过SQS构建分布式云前端来处理 客户连接。这个前端将只是一个包装，即将 验证客户端，并将它们中继到SQS队列。
管理数百万个队列对于“SQS上的分布式云前端”来说可能是一项艰巨的任务。除非您的项目完全与队列管理有关，否则这可能是无差别的繁重工作。
这是我不知道你的情况所能说的全部内容，但考虑到你可以将SNS / SQS与其他消息软件（如Apache Camel和其他消息）一起使用，这可以帮助您构建解决方案或证据的概念。
答案 1 :(得分：1)
我认为SQS（或SNS，如果你最终可以使用它们）仍然是你最好的选择，特别是如果你需要“快速反应”或“接近实时”;但是，为了拥有“替代品”，你可以比较......
你可以考虑一个巨大的dynamoDB，每个设备/客户端都拥有自己的“device-id”，也许还有“message-id”作为密钥。这样，您的设备就可以查询自己的消息密钥。 DynamoDB旨在处理数十亿行，因此这不会给它带来太多压力。查询部分，你应该小心，因为你可以使用配置查询，虽然在汇总级别，你的设备可能不会同时响应/查询，所以你可能仍然没问题。
您还可以考虑拥有一个巨大的S3存储桶，每个文件夹键入设备ID并进一步键入message-id文件夹。这是一个穷人的SQS，但它可以保证在消息数量和访问次数方面进行扩展。
在＃1和＃2中，如果您的设备在Cognito中注册了凭据，则可以采用直接的方式执行策略，因此设备只能访问其“自己”的内容。但是，＃1和＃2两种选择都可能比SQS慢，特别是如果你使用SQS长轮询 - 在长轮询中，一旦SQS检测到一条消息被丢弃，你就得到响应......这些替代方案将会要求你等待下一轮周期轮询。