RabbitMQ 有三種模式：單機模式，普通集群模式，鏡像集群模式：

1.單機模式

單機模式就是說只有一臺機器部署了一個 RabbitMQ 程序。這臺機器宕機后就玩不轉了。

2.普通集群模式

這個模式的意思就是在多臺機器上啟動多個 RabbitMQ 實例。類似的 master-slave 模式一樣。但是創建的 queue，只會放在一個 master rabbtimq 實例上，其他實例都同步那個接收消息的 RabbitMQ 元數據。

在消費消息的時候，如果你連接到的 RabbitMQ 實例不是存放 queue 數據的實例，這個時候 RabbitMQ 就會從存放 queue 數據的實例上拉去數據，然后返回給客戶端。

總的來說，這種方式有點麻煩，沒有做到真正的分布式，每次消費者連接一個實例后拉取數據，如果連接到不是存放 queue 數據的實例，這個時候會造成額外的性能開銷。如果從放 queue 的實例拉取，會導致單實例性能瓶頸。

如果放 queue 的實例宕機了，會導致其他實例無法拉取數據，這個集群都無法消費消息了，沒有做到真正的高可用。

所以這個事兒就比較尷尬了，這就沒有什么所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集群中多個節點來服務某個 queue 的讀寫操作。

3.鏡像集群模式

鏡像集群模式才是真正的 RabbitMQ 的高可用模式，跟普通集群模式不一樣的是：創建的 queue 無論元數據還是 queue 里的消息都會存在于多個實例上，每次寫消息到 queue 的時候，都會自動把消息到多個實例的 queue 里進行消息同步。

這樣的話任何一個機器宕機了別的實例都可以用提供服務，這樣就做到了真正的高可用了。

但是也存在著不好之處：

• 性能開銷過高，消息需要同步所有機器，會導致網絡帶寬壓力和消耗很重
• 擴展性低：無法解決某個 queue 數據量特別大的情況，導致 queue 無法線性拓展。就算加了機器，那個機器也會包含 queue 的所有數據，queue 的數據沒有做到分布式存儲。

對于 RabbitMQ 的高可用一般的做法都是開啟鏡像集群模式，這樣起碼來說做到了高可用，一個節點宕機了，其他節點可以繼續提供服務。

本章節部分參考 https://gitbook.cn/books/5d65124b2b27dd24ed390665/index.html

總結

以上是生活随笔為你收集整理的RabbitMQ 入门系列（7）— 如何保证 RabbitMQ 高可用性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。