分佈式消息隊列：如何保證消息隊列的高可用

RabbitMQ的高可用性

RabbitMQ是比較有表明性的，由於是基於主從作高可用性的，咱們就以他爲例子講解第一種MQ的高可用性怎麼實現。

rabbitmq有三種模式

• 單機模式
• 普通集羣模式
• 鏡像集羣模式

單機模式

就是demo級別的，通常就是你本地啓動了玩玩兒的，沒人生產用單機模式

普通集羣模式

在多臺機器上啓動多個RabbitMQ實例，每一個機器啓動一個。可是你建立的queue只會放在一個rabbitMQ實例上，可是每一個實例都同步queue的元數據。完了你消費的時候，實際上若是鏈接到了另一個實例，那麼那個實例會從queue所在實例上拉去數據過來。這種方式確實很麻煩，也不怎麼好，沒作到所謂的分佈式，就是普通集羣。由於這致使你要麼消費者每次隨機鏈接一個實例而後拉取數據，要麼固定鏈接那個queue所在實例消費數據，前者有數據拉取的開銷，後者致使單實例性能瓶頸。

並且若是那個放queue的實例宕機了，會致使接下來其餘實例就沒法從那個實例拉取，若是你開啓了消息持久化，讓rabbitMQ落地存儲消息的話，消息不必定會丟失，得等這個實例恢復了，而後才能夠繼續從這個queue拉取數據。因此這個狀況就比較尷尬，沒有什麼所謂的高可用性可言，這個方案主要是提升吞吐量，就是說讓集羣中多個節點來服務某個queue的讀寫操做。

鏡像集羣模式

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

這樣的話，好處在於：

• 你任何一個機器宕機了，沒事兒，別的機器均可以用。

壞處在於：

• 這個性能開銷也太大了吧，消息同步全部機器，致使網絡帶寬壓力和消耗很重！
• 這麼玩兒，就沒有擴展性可言了，若是某個queue負載很重，你加機器，新增的機器也包含了這個queue的全部數據，並無辦法線性擴展你的queue那麼怎麼開啓這個鏡像集羣模式呢？

這裏簡單說一下，避免面試人家問你你不知道，其實很簡單rabbitmq有很好的管理控制檯，就是在後臺新增一個策略，這個策略是鏡像集羣模式的策略，指定的時候能夠要求數據同步到全部節點的，也能夠要求就同步到指定數量的節點，而後你再次建立queue的時候，應用這個策略，就會自動將數據同步到其餘的節點上去了。

kafka的高可用性

kafka一個最基本的架構認識：多個broker組成，每一個broker是一個節點；你建立一個topic，這個topic能夠劃分爲多個partition，每一個partition能夠存在於不一樣的broker上，每一個partition就放一部分數據。

這就是自然的分佈式消息隊列，就是說一個topic的數據，是分散放在多個機器上的，每一個機器就放一部分數據。 

實際上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，那麼就要care數據一致性的問題，系統複雜度過高，很容易出問題。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架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）

爲何某些人會一直比你優秀，是由於他自己就很優秀還一直在持續努力變得更優秀，而你是否是還在知足於現狀心裏在竊喜！

關注後臺私信關鍵詞【架構】便可免費獲取資料，無套路關注公衆號免費贈送，且公衆號會不斷更新技術乾貨及粉絲福利！

（部分資料以下）​

​