mq和kafaka架構方面對比高可用性


這一次我們就來說說消息隊列的高可用的原理。這里主要講的是現在使用比較多的RabbitMQ和大數據相關的Kafka兩種消息中間件的高可用。這里只是講解他們的實現原理,不會實戰。

 

1、RabbitMQ的高可用

RabbitMQ是基於主從復制來實現高可用的,不支持分布式。既然是主從復制,那么肯定就不是單台機器能保證的,所以是通過集群來保證高可用。而RabbitMQ的集群模式有兩種:普通集群和鏡像集群。真正實現高可用的是鏡像集群模式。

1.1 普通集群模式

 

 

圖中注釋已經講解了,該集群模式不能保證高可用,它的作用只是提高了系統的吞吐量,同一個隊列的消息,可以有多個消費者去消費。而且它的缺點是:在實例之間會產生網絡傳輸,增加系統開銷。

而且如果那個存有queue的真實數據的實例宕機了,會導致接下來其他實例都無法拉取數據;如果沒有開啟消息的持久化會丟失消息;就算開啟了消息的持久化,消息不一定會丟,但是也要等這個實例恢復了,才可以繼續拉取數據。

1.2 鏡像集群模式

 

 

這種集群模式是可以保證可用的,因為每個實例都存有完整的數據,就算其中的某一個實例宕機了,也只是這一個實例不能提供服務,其他的實例都能繼續提供服務。

不過它也有缺點:

1、性能消耗太大,所有機器都要進行消息的同步,導致網絡壓力和消耗很大。

2、沒有擴展性可言,如果有一個queue負載很重,就算加了機器,新增的機器還是包含了這個queue的所有數據,並沒有辦法擴展queue。

      實際上RabbitMQ並不是分布式消息隊列,他就是傳統的消息隊列,只不過提供了一些集群、HA的機制而已,因為無論如何配置,rabbitmq一個queue的數據就存放在一個節點里面,鏡像集群下,也是每個節點都放這個queue的全部數據。

1.3 開啟鏡像集群
       在控制台新增一個鏡像集群模式的策略,指定的時候可以要求數據同步到所有節點,也可以要求同步到指定節點,然后在創建queue的時候,應用這個策略,就會自動將數據同步到其他的節點上面去了。

 

2、Kafka的高可用     

 

  Kafka的一個基本架構:多個broker組成,一個broker是一個節點;一個topic可以划分成多個partition,每個partition可以存在於不同的broker上面,每個partition存放一部分數據。這是天然的分布式消息隊列。

      Kafka在0.8以前是沒有HA機制的,也就是說任何一個broker宕機了,那個broker上的partition就丟了,沒法讀也沒法寫,沒有什么高可用可言。

      Kafka在0.8之后,提過了HA機制,也就是replica副本機制。每個partition的數據都會同步到其他機器上,形成自己的replica副本。然后所有的replica副本會選舉一個leader出來,那么生產者消費者都和這個leader打交道,其他的replica就是follower。寫的時候,leader會把數據同步到所有follower上面去,讀的時候直接從leader上面讀取即可。

 

 

為什么只能讀寫leader:因為要是你可以隨意去讀寫每個follower,那么就要關心數據一致性問題,系統復雜度太高,容易出問題。kafka會均勻度講一個partition的所有數據replica分布在不同的機器上,這樣就可以提高容錯性。
這樣就是高可用了,因為如果某個broker宕機 了,沒事兒,那個broker的partition在其他機器上有副本,如果這上面有某個partition的leader,那么此時會重新選舉出一個新的leader出來,繼續讀寫這個新的leader即可。

寫消息: 寫數據的時候,生產者就寫向leader,然后leader將數據落到磁盤上之后,接着其他follower自己主動從leader來pull數據。一旦所有follower同步好了數據,就會發送ack給leader,leader收到了所有的follower的ack之后,就會返回寫成功的消息給消息生產者。(這只是一種模式,可以調整)。
讀數據: 消費數據的時候,只會從leader進行消費。但是只有一個消息已經被所有follower都同步成功返回ack的時候,這個消息才會被消費者讀到。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM