RocketMQ 保證其高可用
RocketMQ 分佈式集羣是通過Master和Slave的配合達到高可用性的，Master 角色的 Broker 支持讀和寫，Slave 角色的 Broker 僅支持讀，也就是 Producer 只能和 Master 角色的 Broker 連接寫人消息；Consumer 可以連接 Master 角色的 Broker，也可以連接 Slave 角色的 Broker 來讀取消息
消費端的高可用性
Master 不可用或者繁忙的時候，Consumer 會被自動切換到從 Slave 讀。有了自動切換Consumer這種機制，當一個 Master 角色的機器出現故障後，Consumer 仍然可以從 Slave 讀取消息，不影響Consumer 程序。這就達到了消費端的高可用性。
發送端的高可用性
在創建 Topic 的時候，把 Topic 的 MessageQueue 創建在多個 Broker 組上（相同Broker名稱，不同brokerId的機器組成一個Broker組），這樣當一個 Broker 組的 Master 不可用後，其他組的 Master 仍然可用，Producer 仍然可以發送消息。
Kafka 保證其高可用
Kafka 有多個 broker，每個broker 就是一個節點
KafKa每創建一個Topic，這個Topic 可以劃分爲多個partition，每個partition 可以存在於不同的 broker 中，每個partition 中只放部分數據，保證了Kafka的分佈式部署
Kafka引入了副本機制 replica ，每個partition 都會將消息同步到其他的機器上，然後從這些機器通過ZK的leader的選舉方式出來一個leader，其他的作爲follower，讀寫在leader上進行操作。即便是leader 宕機了，會從剩餘的follower中再次快速選舉出來一個leader，保證高可用
RabbitMQ 保證其高可用
RabbitMQ集羣部署：（普通集羣部署和鏡像集羣部署）
RabbitMQ不支持分佈式部署，因爲RabbitMQ的數據是全部放在一臺機器上的
普通集羣部署：
將一個RabbitMQ的實例放到多個機器上，創建的MQ的queue只會放在一個RabbitMQ的實例上，其他的MQ去同步這個機器上的實例，但是隻是同步的元數據，元數據標識了這個數據所在的機器等信息，當消費者消費到了元數據，會根據元數據找到對應的實例數據
缺點：實例宕機對消息消費的影響較大
優點：提高吞吐量，因爲對應的是集羣
鏡像集羣模式
創建的元數據和queue中的消息都會存在於多個機器上，能保證高可用，即便是一個機器宕機，也能保證其他的機器繼續服務於消費者和生產者
缺點：性能開銷大，一直在同步消息；消息存在於一臺機器上，消息積壓不好處理
