分布式系统中的状态复制协调非常困难。在一系列联网过程中如何共享状态数据信息并彼此保持同步？最近，RabbitMQ团队发布了一种新型的队列，该队列使用Raft Consensus算法在集群中提供了持久的，先进先出的排队体验。这非常适合您无法承受数据丢失并且还希望集群环境提供高可用性的方案。由于RabbitMQ广受欢迎并在各地使用，因此我认为深入研究仲裁队列很有趣，并提供一个示例，您可以沿用。
仲裁队列是在2019年秋季发布的RabbitMQ 3.8大版本的一部分，是镜像队列的后继者，并以多种方式对其进行了改进。默认情况下，队列位于群集中的单个节点上。显然，位于单个节点上的设备可能会出现宕机风险！因此，我们通过创建集群来减轻这种风险。镜像队列具有一个主节点，并且跨集群中的辅助节点进行镜像以实现高可用性。如果主服务器发生故障，则将升级其中一个镜像，然后继续处理。我的新同事杰克有一个很棒的帖子有关仲裁队列如何“解决”镜像队列的一些同步和存储难题。它们是一个很好的改进，这就是为什么我想对其进行一些探索的原因。
Spring Boot试验细节点击标题进入原文。试验内容大概是：
开启第一个应用是消息发布者，第二个应用是消息的订阅者，第三个应用将在时间到时关闭RabbitMQ节点，模拟故障宕机。
开启消息发布，会看到发布者正在发布，订阅者正在订阅。消息从仲裁队列按顺序到达。然后关闭RabbitMQ三个节点中一个，但是处理过程中没有暂停，并且Spring Boot应用程序保持愉快地按顺序发送和接收数据。仲裁队列有了新的领导者，并且三个集群成员中只有两个处于联机状态。
为了娱乐，再次启动已停止的节点，发现它迅速重新加入群集并再次开始参与仲裁队列。