1、面試題
如何保證訊息佇列的高可用啊？
2、面試官心理分析
如果有人問到你mq的知識，高可用是必問的，因為mq的缺點，我剛才已經說過了，有好多，導致系統可用性降低，等等。所以只要你用了mq，接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。
要是你傻乎乎的就乾用了乙個mq，各種問題從來沒考慮過，那你就杯具了，面試官對你的印象就是，只會簡單實用一些技術，沒任何思考，馬上對你的印象就不太好了。這樣的同學招進來要是做個20k薪資以內的普通小弟還湊合。如果招進來做薪資20多k的高工，那就慘了，讓你設計個系統，裡面肯定一堆坑，出了事故公司受損失，團隊一起背鍋。
去年的事兒，非常大的網際網路公司，非常核心的系統，就是疏忽了mq，沒考慮mq如何保證高可用，如果mq掛了怎麼辦，導致幾個小時系統不可用，公司損失幾千萬，team背鍋，你鬧的禍，你老大幫你一起背鍋
3、面試題剖析
這個問題這麼問是很好的，因為不能問你kafka的高可用性怎麼保證啊？activemq的高可用性怎麼保證啊？乙個面試官要是這麼問就顯得很沒水平，人家可能用的就是rabbitmq，沒用過kafka，你上來問人家kafka幹什麼？這不是擺明了刁難人麼。
所以有水平的面試官，問的是mq的高可用性怎麼保證？這樣就是你用過哪個mq，你就說說你對那個mq的高可用性的理解。
（1）rabbitmq的高可用性
rabbitmq是比較有代表性的，因為是基於主從做高可用性的，我們就以他為例子講解第一種mq的高可用性怎麼實現。
rabbitmq有三種模式：單機模式，普通集群模式，映象集群模式
1）單機模式
就是demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產用單機模式
2）普通集群模式
意思就是在多台機器上啟動多個rabbitmq例項，每個機器啟動乙個。但是你建立的queue，只會放在乙個rabbtimq例項上，但是每個例項都同步queue的元資料。完了你消費的時候，實際上如果連線到了另外乙個例項，那麼那個例項會從queue所在例項上拉取資料過來。
這種方式確實很麻煩，也不怎麼好，沒做到所謂的分布式，就是個普通集群。因為這導致你要麼消費者每次隨機連線乙個例項然後拉取資料，要麼固定連線那個queue所在例項消費資料，前者有資料拉取的開銷，後者導致單例項效能瓶頸。
而且如果那個放queue的例項宕機了，會導致接下來其他例項就無法從那個例項拉取，如果你開啟了訊息持久化，讓rabbitmq落地儲存訊息的話，訊息不一定會丟，得等這個例項恢復了，然後才可以繼續從這個queue拉取資料。
所以這個事兒就比較尷尬了，這就沒有什麼所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集群中多個節點來服務某個queue的讀寫操作。
3）映象集群模式
這種模式，才是所謂的rabbitmq的高可用模式，跟普通集群模式不一樣的是，你建立的queue，無論元資料還是queue裡的訊息都會存在於多個例項上，然後每次你寫訊息到queue的時候，都會自動把訊息到多個例項的queue裡進行訊息同步。
這樣的話，好處在於，你任何乙個機器宕機了，沒事兒，別的機器都可以用。壞處在於，第一，這個效能開銷也太大了吧，訊息同步所有機器，導致網路頻寬壓力和消耗很重！第二，這麼玩兒，就沒有擴充套件性可言了，如果某個queue負載很重，你加機器，新增的機器也包含了這個queue的所有資料，並沒有辦法線性擴充套件你的queue
那麼怎麼開啟這個映象集群模式呢？我這裡簡單說一下，避免面試人家問你你不知道，其實很簡單rabbitmq有很好的管理控制台，就是在後台新增乙個策略，這個策略是映象集群模式的策略，指定的時候可以要求資料同步到所有節點的，也可以要求就同步到指定數量的節點，然後你再次建立queue的時候，應用這個策略，就會自動將資料同步到其他的節點上去了。
（2）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的時候，這個訊息才會被消費者讀到。
實際上這塊機制，講深了，是可以非常之深入的，但是我還是回到我們這個課程的主題和定位，聚焦面試，至少你聽到這裡大致明白了kafka是如何保證高可用機制的了，對吧？不至於一無所知，現場還能給面試官畫畫圖。要遇上面試官確實是kafka高手，深挖了問，那你只能說不好意思，太深入的你沒研究過。
但是大家一定要明白，這個事情是要權衡的，你現在是要快速突擊常見面試題體系，而不是要深入學習kafka，要深入學習kafka，你是沒那麼多時間的。你只能確保，你之前也許壓根兒不知道這塊，但是現在你知道了，面試被問到，你大概可以說一說。然後很多其他的候選人，也許還不如你，沒看過這個，被問到了壓根兒答不出來，相比之下，你還能說點出來，大概就是這個意思了。
原文：
HDFS如何保證高可用性
1 實現方式 namenode冗餘備份 2 具體過程 多個節點作為namenode，其中乙個處於active狀態，其它處於standby狀態。目前的實現有乙個條件，需要借助類似nfs這樣的分布式共享儲存系統，而且節點要能夠訪問這一系統。在active的namespace上的每個改變，需要同步到處於s...
如何保證訊息佇列高可用性？
當前位置 home mq 如何保證訊息佇列高可用性？rabbitmq的高可用性 rabbitmq 是比較有代表性的，因為是基於主從 非分布式 做高可用性 三種模式 單機模式 普通集群模式 映象集群模式 單機模式 是demo級別 普通集群模式 無高可用性 再多台機器上啟動多個rabbitmq例項。每台...
如何保證訊息佇列的高可用性？
1 rabbitmq的高可用性 rabbitmq是比較有代表性的，因為是基於高可用性的，以下是它的高可用性的實現。1.普通集群模式 在多台機器上啟動多個rabbitmq例項，每個機器啟動乙個。但是你建立的queue只會放在乙個rabbitmq例項上，但是每個例項都同步queue的元資料。完了你消費的...