RabbitMQ的高可用性
RabbitMQ是基於主從做高可用性的，有三種模式：單機模式，普通集群模式，鏡像集群模式
單機模式：
demo級別
普通集群模式：
在多台機器上啟動rabbitmq實例，每個機器啟動一個。
但是你創建的queue，只會放在一個rabbtimq實例上，每個實例都同步queue的元數據。
消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從queue所在實例上拉取數據過來。 這種方式沒做到所謂的分布式，就是個普通集群。
如果那個放queue的實例宕機了，會導致接下來其他實例就無法從那個實例拉取。
所以這就沒有什么所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集群中多個節點來服務某個queue的讀寫操作。
鏡像集群模式：
這種模式，才是所謂的rabbitmq的高可用模式
你創建的queue，無論元數據還是queue里的消息都會存在於多個實例上，然后每次你寫消息到queue的時候，都會自動把消息到多個實例的queue里進行消息同步。
這樣的話，好處在於，你任何一個機器宕機了，別的機器都可以用。
壞處在於，第一，性能開銷大，消息同步所有機器，導致網絡帶寬壓力和消耗很重！
第二，沒有擴展性，如果某個queue負載很重，你加機器，新增的機器也包含了這個queue的所有數據，並沒有辦法線性擴展你的queue
開啟鏡像集群模式：rabbitmq有很好的管理控制台，在后台新增一個策略，這個策略是鏡像集群模式的策略，指定的時候可以要求數據同步到所有節點的，也可以要求就同步到指定數量的節點，然后你再次創建queue的時候，應用這個策略，就會自動將數據同步到其他的節點上去了。
kafka的高可用性
kafka一個最基本的架構認識：多個broker組成，每個broker是一個節點。
創建一個topic，這個topic可以划分為多個partition，每個partition可以存在於不同的broker上，每個partition就放一部分數據，這就是天然的分布式消息隊列。
kafka 0.8以后，提供了HA機制，就是replica副本機制。每個partition的數據都會同步到其他機器上，形成自己的多個replica副本。
然后所有replica會選舉一個leader出來，那么生產和消費都跟這個leader打交道，然后其他replica就是follower。
寫的時候，leader會負責把數據同步到所有follower上去，讀的時候就直接讀leader上數據即可。
kafka會均勻的將一個partition的所有replica分布在不同的機器上，這樣才可以提高容錯性。
如果某個broker宕機了，沒事，那個broker上面的partition在其他機器上都有副本的，如果這上面有某個partition的leader，那么此時會重新選舉一個新的leader出來，大家繼續讀寫那個新的leader即可。
寫數據的時候，生產者就寫leader，然后leader將數據落地寫本地磁盤，接着其他follower自己主動從leader來pull數據。一旦所有follower同步好數據了，就會發送ack給leader，leader收到所有follower的ack之后，就會返回寫成功的消息給生產者。（當然，這只是其中一種模式，還可以適當調整這個行為）
消費的時候，只會從leader去讀，但是只有一個消息已經被所有follower都同步成功返回ack的情況下，這個消息才會被消費者讀到。
轉自：中華石杉Java工程師面試突擊