我在AWS内部的EC2实例上有一个中央c#窗口服务。它的工作是创建任务(JSON中的指令(，然后将其发送到在AWS外部服务器上运行的各个Windows服务(想想实体零售店，每家商店都有服务器(。
这些单独的服务器根据 JSON 任务执行一些处理，然后将消息发送回 AWS 内部的中央 Windows 服务。 此设计当前使用的是 AWS SQS。
我最初设计了这个，使用 1 个 SQS 队列来处理发往外部服务器的消息，使用 1 个 SQS 队列来处理返回的消息。总共两个队列。
然而，这种设计似乎有缺陷，因为某些消息仅适用于某些服务器，但为了确定哪个消息适用于哪个服务器，必须从队列中"读取"消息并检查 JSON，然后将它们隐藏起来，防止其他服务器轮询消息。这可能导致服务器永远看不到他们的消息，因为它们不断被其他服务器隐藏。
那么我有什么替代方案可以替代这种设计呢？AWS 外部有 400 台服务器。我可以有 400 个 SQS 队列(每个服务器一个(，然后一个队列返回到中央服务？似乎有很多队列。
我想过使用SNS？但是我仍然有 400 个 SNS 主题，对吧？每家店一个？
您绝对不应该检索不会被处理的 Amazon SQS 消息。这可能会导致所需服务器永远不会检索邮件的情况。
您的选择是：
- 为每个服务器创建一个队列。他们检查自己的队列。或
- 使用 API 网关创建您自己的 API。服务器呼叫，标识自己。消息从数据库(不是 SQS(中检索并提供回。缺点：你必须自己编写，做错误处理，隐形类型的功能等。
第一个选项是最简单的，几乎不需要更改编码。SQS 中的队列数量似乎没有限制。可以使用几行代码以编程方式创建 400 个队列。
根据应用程序的运行方式，您可能还需要一个任何服务器都可以抓取的常规队列，甚至可能需要特定类别的服务器的队列(例如，按地理位置或功能(。每个服务器将首先检查自己的队列，然后检查其类的队列，然后检查常规队列。
需要注意的是：Amazon SQS 按 API 调用(例如尝试检索消息(收费。使用长轮询来减少请求数。
解决方案是SQS。通读 http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-attributes.html
任何存储都可以使用的消息将没有任何消息属性;而特定存储的消息将具有属性 store=store1。
现在，所有存储都将有两个侦听器，一个具有消息属性;而一个侦听器没有过滤器。
如果您有任何疑问，请通知我。
正如约翰所建议的那样，我的上述答案可能不起作用; 一种解决方案可以使用我使用过的任何 JMS 解决方案提供程序，例如 ActiveMQ，并且肯定提供此功能;您可以在其中订阅基于筛选器的队列。
bitnami 为 activemq 提供了一个 AMI，您可以将其安装在微型 EC2 实例上。它非常直接。