關於MQ的幾件小事（二）如何保證消息隊列的高可用

1.RabbitMQ的高可用

RabbitMQ基於主從模式實現高可用。RabbitMQ有三種模式：單機模式，普通集羣模式，鏡像集羣模式。 （1）單機模式： 單機模式就是demo級別的，生產中不會有人使用。 （2）普通集羣模式 普通集羣模式就是在多臺機器上啓動多個rabbitmq實例，每一個機器啓動一個。可是建立的queue只會放在一個rabbitmq實例上面，可是其餘的實例都同步了這個queue的元數據。在你消費的時候，若是鏈接到了另外一個實例，他會從擁有queue的那個實例獲取消息而後再返回給你。

這種方式並無作到所謂消息的高可用，就是個普通的集羣，這樣還會致使要麼消費者每次隨機鏈接一個實例而後拉取數據，這樣的話在實例之間會產生網絡傳輸，增長系統開銷，要麼固定鏈接那個queue所在的實例消費，這樣會致使單實例的性能瓶頸。

並且若是那個方queue的實例宕機了，會致使接下來其餘實例都沒法拉取數據；若是沒有開啓消息的持久化會丟失消息；就算開啓了消息的持久化，消息不必定會丟，可是也要等這個實例恢復了，才能夠繼續拉取數據。 因此這個並無提供高可用，這種方案只是提升了吞吐量，也就是讓集羣中多個節點來服務某個queue的讀寫操做。 （3）鏡像集羣模式 這種模式，纔是rabbitmq提供是真正的高可用模式，跟普通集羣不同的是，你建立的queue，不管元數據仍是queue裏面是消息數據都存在多個實例當中，而後每次寫消息到queue的時候，都會自動把消息到多個queue裏進行消息同步。

這種模式的好處在於，任何一臺機器宕機了，其餘的機器還可使用。
壞處在於： 一、性能消耗太大，全部機器都要進行消息的同步，致使網絡壓力和消耗很大。二、沒有擴展性可言，若是有一個queue負載很重，就算加了機器，新增的機器仍是包含了這個queue的全部數據，並無辦法擴展queue。
如何開啓鏡像集羣模式： 在控制檯新增一個鏡像集羣模式的策略，指定的時候能夠要求數據同步到全部節點，也能夠要求同步到指定節點，而後在建立queue的時候，應用這個策略，就會自動將數據同步到其餘的節點上面去了。

2.kafka的高可用

（1）kafka的一個基本架構：多個broker組成，一個broker是一個節點；你建立一個topic，這個topic能夠劃分紅多個partition，每一個partition能夠存在於不一樣的broker上面，每一個partition存放一部分數據。這是自然的分佈式消息隊列。

實際上rabbitmq並非分佈式消息隊列，他就是傳統的消息隊列，只不過提供了一些集羣、HA的機制而已，由於不管如何配置，rabbitmq一個queue的數據就存放在一個節點裏面，鏡像集羣下，也是每一個節點都放這個queue的所有數據。

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的時候，這個消息纔會被消費者讀到。

上一篇《消息隊列的用途、優缺點、技術選型》
下一篇《如何保證消息不重複消費》