分散式系統中的狀態複製協調非常困難。在一系列聯網過程中如何共享狀態資料資訊並彼此保持同步？最近，RabbitMQ團隊釋出了一種新型的佇列，該佇列使用Raft Consensus演算法在叢集中提供了持久的，先進先出的排隊體驗。這非常適合您無法承受資料丟失並且還希望叢集環境提供高可用性的方案。由於RabbitMQ廣受歡迎並在各地使用，因此我認為深入研究仲裁佇列很有趣，並提供一個示例，您可以沿用。

仲裁佇列是在2019年秋季釋出的RabbitMQ 3.8大版本的一部分，是映象佇列的後繼者，並以多種方式對其進行了改進。預設情況下，佇列位於群集中的單個節點上。顯然，位於單個節點上的裝置可能會出現當機風險！因此，我們通過建立叢集來減輕這種風險。映象佇列具有一個主節點，並且跨叢集中的輔助節點進行映象以實現高可用性。如果主伺服器發生故障，則將升級其中一個映象，然後繼續處理。我的新同事傑克有一個很棒的帖子有關仲裁佇列如何“解決”映象佇列的一些同步和儲存難題。它們是一個很好的改進，這就是為什麼我想對其進行一些探索的原因。

Spring Boot試驗細節點選標題進入原文。試驗內容大概是：

開啟第一個應用是訊息釋出者，第二個應用是訊息的訂閱者，第三個應用將在時間到時關閉RabbitMQ節點，模擬故障當機。

開啟訊息釋出，會看到釋出者正在釋出，訂閱者正在訂閱。訊息從仲裁佇列按順序到達。然後關閉RabbitMQ三個節點中一個，但是處理過程中沒有暫停，並且Spring Boot應用程式保持愉快地按順序傳送和接收資料。仲裁佇列有了新的領導者，並且三個叢集成員中只有兩個處於聯機狀態。

為了娛樂，再次啟動已停止的節點，發現它迅速重新加入群集並再次開始參與仲裁佇列。