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工程師面試突擊