如何保證消息隊列的高可用？
面試題
如何保證消息隊列的高可用？
面試官心理分析
如果有人問到你 MQ 的知識，高可用是必問的。上一講提到，MQ 會導致系統可用性降低。所以只要你用了 MQ，接下來問的一些要點肯定就是圍繞着 MQ 的那些缺點怎麼來解決了。
要是你傻乎乎的就幹用了一個 MQ，各種問題從來沒考慮過，那你就杯具了，面試官對你的感覺就是，只會簡單使用一些技術，沒任何思考，馬上對你的印象就不太好了。這樣的同學招進來要是做個 20k 薪資以內的普通小弟還湊合，要是做薪資 20k+ 的高工，那就慘了，讓你設計個系統，裏面肯定一堆坑，出了事故公司受損失，團隊一起背鍋。
面試題剖析
這個問題這麼問是很好的，因爲不能問你 Kafka 的高可用性怎麼保證？ActiveMQ 的高可用性怎麼保證？一個面試官要是這麼問就顯得很沒水平，人家可能用的就是 RabbitMQ，沒用過 Kafka，你上來問人家 Kafka 幹什麼？這不是擺明了刁難人麼。
所以有水平的面試官，問的是 MQ 的高可用性怎麼保證？這樣就是你用過哪個 MQ，你就說說你對那個 MQ 的高可用性的理解。
RabbitMQ 的高可用性
RabbitMQ 是比較有代表性的，因爲是基於主從（非分佈式）做高可用性的，我們就以 RabbitMQ 爲例子講解第一種 MQ 的高可用性怎麼實現。
RabbitMQ 有三種模式：單機模式、普通集羣模式、鏡像集羣模式。
單機模式
單機模式，就是 Demo 級別的，一般就是你本地啓動了玩玩兒的😄，沒人生產用單機模式。
普通集羣模式（無高可用性）
普通集羣模式，意思就是在多臺機器上啓動多個 RabbitMQ 實例，每個機器啓動一個。你創建的 queue，只會放在一個 RabbitMQ 實例上，但是每個實例都同步 queue 的元數據（元數據可以認爲是 queue 的一些配置信息，通過元數據，可以找到 queue 所在實例）。你消費的時候，實際上如果連接到了另外一個實例，那麼那個實例會從 queue 所在實例上拉取數據過來。
這種方式確實很麻煩，也不怎麼好，沒做到所謂的分佈式，就是個普通集羣。因爲這導致你要麼消費者每次隨機連接一個實例然後拉取數據，要麼固定連接那個 queue 所在實例消費數據，前者有數據拉取的開銷，後者導致單實例性能瓶頸。
而且如果那個放 queue 的實例宕機了，會導致接下來其他實例就無法從那個實例拉取，如果你開啓了消息持久化，讓 RabbitMQ 落地存儲消息的話，消息不一定會丟，得等這個實例恢復了，然後纔可以繼續從這個 queue 拉取數據。
所以這個事兒就比較尷尬了，這就沒有什麼所謂的高可用性，這方案主要是提高吞吐量的，就是說讓集羣中多個節點來服務某個 queue 的讀寫操作。
鏡像集羣模式（高可用性）
這種模式，纔是所謂的 RabbitMQ 的高可用模式。跟普通集羣模式不一樣的是，在鏡像集羣模式下，你創建的 queue，無論元數據還是 queue 裏的消息都會存在於多個實例上，就是說，每個 RabbitMQ 節點都有這個 queue 的一個完整鏡像，包含 queue 的全部數據的意思。然後每次你寫消息到 queue 的時候，都會自動把消息同步到多個實例的 queue 上。
那麼如何開啓這個鏡像集羣模式呢？其實很簡單，RabbitMQ 有很好的管理控制檯，就是在後臺新增一個策略，這個策略是鏡像集羣模式的策略，指定的時候是可以要求數據同步到所有節點的，也可以要求同步到指定數量的節點，再次創建 queue 的時候，應用這個策略，就會自動將數據同步到其他的節點上去了。
這樣的話，好處在於，你任何一個機器宕機了，沒事兒，其它機器（節點）還包含了這個 queue 的完整數據，別的 consumer 都可以到其它節點上去消費數據。壞處在於，第一，這個性能開銷也太大了吧，消息需要同步到所有機器上，導致網絡帶寬壓力和消耗很重！第二，這麼玩兒，不是分佈式的，就沒有擴展性可言了，如果某個 queue 負載很重，你加機器，新增的機器也包含了這個 queue 的所有數據，並沒有辦法線性擴展你的 queue。你想，如果這個 queue 的數據量很大，大到這個機器上的容量無法容納了，此時該怎麼辦呢？
來源:“創享視界”，創享視界(creativeview.cn)是一個帶動全民顛覆八小時工作制，通過投稿把自己的創意智慧變現的方式創造被動收入，從而實現財務自由的平臺。我們相信，創新思維不僅有助於打造更出色的產品，還可以讓世界變得更美好，讓人人受益。