使用 Amazon SQS 和 SNS 设计推送队列，如何？

Question

现在：

• App #1 向 SQS 插入消息
• .Net 工作者角色轮询队列，如果发现消息将其发送到 App #2 进行处理，则等待 App #2 完成并重新开始轮询队列
• App #2 处理消息，这是一项漫长而繁重的任务

由于 App #2 可能需要很长时间来处理消息，并且我无法预测 App #1 同时发送了多少消息，队列系统向我保证 App #2 不会耗尽资源并且系统可以很容易扩展。但是有一个我想解决的问题：我不希望有一台机器来运行辅助角色（现在在 Azure 上）只是为了轮询队列（所有东西都托管在其他地方，辅助角色不是一个选项）。此外，由于轮询之间的暂停，轮询永远不会像推送那样响应迅速。

从 poll 切换到 push 听起来是正确的路径，但我需要保证即使在一秒钟内从 App #1 发送 1k 条消息，App #2 也会一一处理它们并且不会被点击 1k 次每秒。

我正在计划一个设计，其中 App #1 发布到 SNS 主题，其订阅者是 SQS 和 App #2。 App #2 检查 SQS 队列，如果为空则退出，如果不是，则一一处理消息然后退出。但是我如何编码 App #2（现在是一个 .Net Web/Web 服务），以便如果它已经在处理消息并从 SNS 接收通知，它什么也不做并退出（如果不运行多个处理）。

对如何设计有什么建议吗？我读了this blog post，但我不知道如何避免处理应用同时处理多条消息。

Answer 1

如果您将 SNS 角色视为缩短轮询“睡眠间隔”的一种方式，那么您只需不更改任何查询能力，应用程序 #2 仍将按照自己的意愿处理消息，但如果它“睡眠” " 通知将唤醒它并立即发起投票。

Answer 2

您可以通过使用交付策略来解决所有这些问题，这些策略允许您为端点指定速率限制和重试规则。