【消息隊列】kafka是如何保證高可用的

1、kafka一個最基本的架構認識

　　由多個broker組成，每一個broker就是一個節點；建立一個topic，這個topic能夠劃分爲多個partition，每一個partition能夠存在於不一樣的broker上，每一個partition存放放一部分數據。

　　kafka就是一個分佈式消息隊列，就是說一個topic的數據，是分散放在多個機器上的，每一個機器就放一部分數據。
　　實際上像rabbitmq之類的，並非分佈式消息隊列，它只是傳統的消息隊列，只不過提供了一些集羣、HA的機制而已，由於rabbitmq的一個queue的數據都是放在一個節點裏的，鏡像集羣下，也是每一個節點都存放這個queue的完整數據。

 

 

2、kafka高可用機制

　　kafka 0.8之前，是沒有HA機制的，就是任何一個broker宕機了，那個broker上的partition就廢了，無法寫也無法讀，沒有什麼高可用性可言。

　　kafka 0.8之後，提供了HA機制，就是replica副本機制。每一個partition的數據都會同步到其餘機器上，造成本身的多個replica副本。而後全部replica會選舉一個leader出來，那麼生產和消費都跟這個leader打交道，而後其餘replica就是follower。寫的時候，leader會負責把數據同步到全部follower上去，讀的時候就直接讀leader上數據便可。只能讀寫leader？很簡單，要是你能夠隨意讀寫每一個follower，那麼就要care數據一致性的問題，系統複雜度過高，很容易出問題。kafka會均勻的將一個partition的全部replica分佈在不一樣的機器上，這樣才能夠提升容錯性。

　　kafka的這種機制，就有所謂的高可用性了，由於若是某個broker宕機了，也沒事兒，由於那個broker上面的partition在其餘機器上都有副本的，那麼此時會從新選舉一個新的leader出來，你們繼續讀寫那個新的leader便可。這就有所謂的高可用性了。

1）寫過程

　　寫數據的時候，生產者就寫leader，而後leader將數據落地寫本地磁盤，接着其餘follower本身主動從leader來pull數據。一旦全部follower同步好數據了，就會發送ack給leader，leader收到全部follower的ack以後，就會返回寫成功的消息給生產者。（固然，這只是其中一種模式，還能夠適當調整這個行爲）

 

2）讀過程

　　消費的時候，只會從leader去讀，可是隻有當一個消息已經被全部follower都同步成功並返回ack的時候，這個消息纔可以被消費者讀到。

 

題外話： RabbitMQ的高可用性
　　RabbitMQ是比較有表明性的，由於是基於主從作高可用性的；

rabbitmq有三種模式：單機模式，普通集羣模式，鏡像集羣模式

1.單機模式

　　demo級別，生產不能用單機模式。

 

2.普通集羣模式

　　就是在多臺機器上啓動多個rabbitmq實例，每一個機器啓動一個。可是你建立的queue，只會存放在一個rabbtimq實例上，可是每一個實例都同步queue的元數據。實際上若是鏈接到了另一個實例，那麼那個實例會從真正存有數據的queue所在實例上拉取數據過來。

　　沒作到所謂的分佈式，就是個普通集羣。該方案主要是提升吞吐量的，就是說讓集羣中多個節點來服務某個queue的讀寫操做。

 

 

3.鏡像集羣模式

　　這種模式，纔是所謂的rabbitmq的高可用模式，跟普通集羣模式不同的是，你建立的queue，不管元數據仍是queue裏的消息都會存在於多個實例上，而後每次你寫消息到queue的時候，都會自動把消息到多個實例的queue裏進行消息同步。