Notifications AWS：在多个实例上运行的多个工作进程的广播通知

我在AmazonEC2中有多个应用程序实例，每个实例运行几个工作进程。我希望每个工作进程都订阅一些通知（例如，配置更改）。这个通知基本上应该是广播消息，这样一旦发送，每个工作人员都会收到它

我知道SQS不支持消息广播。通过查看类似的问题/线索，我看到了使用SNS而不是SQS的建议。由于以下原因，我不确定这是否适用于我：

• 应用程序实例是自动缩放组的一部分，因此可以动态添加和删除它们。在这种情况下，一旦实例终止，我看不到任何明确的方法来取消订阅每个worker（每个实例有多个worker），这意味着一段时间后，我将面临一堆死掉的订阅者
• 订阅使用的协议也不清楚。HTTP端点看起来是唯一的选项，这意味着我的每个工作者都应该在自己的端口上运行HTTP服务器。看起来我应该只在实例公共IP上监听，这又增加了一层复杂性和不安全性

目前，我有一个基于第三方的解决方案——我使用的是0MQ发布/订阅服务器。但我正在寻找AWS提供的一些现成的解决方案

谢谢，

---

Vovan

想到的现成AWS解决方案是创建一个SNS主题，然后对于每个实例，当实例启动时，它将创建自己的SQS队列并向SNS主题订阅队列，以便将每个消息发布到SNS

您可能希望在实例终止时取消订阅并删除这些队列，这可以通过

如果您不想使用服务器来管理生命周期挂钩（将启动或终止事件发布到SNS或SQS）的处理，您可以创建一个AWS API网关端点来启动AWS Lambda函数，然后使用https将API网关端点订阅到SNS主题，以处理Lambda中的清理任务，不需要服务器

---

这是多个服务协同工作的结果，听起来可能有点复杂，但成本很低，几乎不需要维护或注意。

我想出的另一个解决方案是使用Amazon Kinesis。这意味着每个订阅者都必须维护自己的检查点，以便只接收最新的通知

我意识到这是一条古老的线索，但我想与大家分享我的经验。Kinesis有一个5读/秒的节流阀。因此，如果您有10个节点每秒轮询一次流中的事件，那么您将处于一个恒定的节流状态。

---

Kinesis看起来主要用于只有几个读卡器的大规模写入，这不太适合广播到多个节点的用例。

您的Kinesis解决方案是否符合您的预期目的。我假设您想要注册多个侦听Kinesis流的侦听器，并且您想要向Kinesis流发送单个消息，并希望每个侦听器对其进行操作