Architecture 关于高可用性发布/订阅体系结构的建议

这似乎是一个相当普遍的问题，但我还没有找到答案。假设我有一个发布/订阅基础设施，并且解决方案的一个组件必须在收到关于主题的消息时采取操作（每个消息只应采取一次操作）。同样重要的是，该组件具有高可用性，并且具有用于负载平衡的主动语义

使用P2P消息传递模式，通过运行多个消费者实例监听同一队列，很容易实现这一点。然而，使用pub/sub时，消费者的每个实例都将收到自己的消息副本，因此同一操作可能会执行多次

我考虑的方法是使用单独的组件，该组件将以主动-被动模式运行，并通过将消息转发到队列（它可以是另一个代理，甚至是类似Redis的东西）将发布/订阅转换为P2P。转换器的两个实例之间将有一条心跳消息，该消息将允许被动实例在主动实例因任何原因断开连接时立即订阅主题

另一种选择是在所有活动实例之间共享存储，一旦一个实例开始处理消息，它就会在存储中指示这一点，这样其他实例就会停止处理消息。我担心这会导致很多争用问题，使得主动-主动配置的好处一无所获

---

我正在寻找其他方法的建议，或者对我列出的方法进行改进

有点不清楚你的制作人（酒吧/酒吧）对你有什么保证。它能支持持久订阅吗

对于您的可用性需求，第一个解决方案可能更可行。执行领导人选举协议是一个很难解决的问题。我建议使用现有的解决方案，比如Zookeeper。无论你选择怎样做，领导人选举至少需要3名成员。例如，3个Zookeeper节点

---

数据库锁定选项将增加延迟，并且根据可用性要求，您需要设置群集。

这有帮助吗？这确实很有帮助，我认为本文类似于第一种方法。但是，它并没有解决单个主题订阅者的高可用性部分，因此仍然需要考虑到这一点。在这种情况下，必须建立某种排队基础设施。Redis可能是其中一种选择。