我正在尝试为 RabbitMQ 的两个数据中心之间提供灾难恢复。在主 DC 出现故障之前，辅助数据中心处于被动状态。
队列联合是不合适的，因为在辅助 DC 中的使用者激活之前它不会移动消息。除非主 DC 不可用(此时这些消息无法访问)，否则这种情况不应该发生。
我考虑过在主 DC 中创建一个额外的队列，该队列将接收每条消息的副本，然后使用 Federation 或 Shovel 将这些消息复制到辅助 DC。然后，问题就变成在处理主 DC 中的“原始”消息时从辅助 DC 中删除重复消息。
将队列镜像到辅助 DC 中的节点是可行的，但由于延迟，RabbitMQ 不会通过 WAN 进行集群。
还有其他人遇到过这种情况吗？谢谢。
最佳答案
您非常 Eloquent 地解释了使用 Federation 和 Shovels 尝试通过 RabbitMq 解决 DR 的问题。 Rabbit 的设计初衷并不是为了通过 WAN 高效地移动数据。
跨 WAN 移动数据总是会给消息传递解决方案带来问题。例如，IBM MQ 具有用于 HA 的多实例队列管理器，但需要用于 DR 的 SAN，这在产品和处理时间方面都变得昂贵。
您可以使用的另一个像 Rabbit 这样的免费产品是 Solace。它内置了 HA 和 DR 复制。它可以通过近乎实时地在 WAN 上异步移动每条消息来管理您描述的主动/被动被动 DR 场景。一旦您准备好将应用程序流量移至备份 DC，您就可以激活备份实例并开始使用消息。当从事件端使用消息时，它会自动“删除重复的消息”。
关于Rabbitmq WAN 上的主动/被动 HA，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43238830/