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
的時候，應用這個策略，就會自動將資料同步到其他的節點上去了。
的高可用性
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
，你是沒那麼多時間的。你只能確保，你之前也許壓根兒不知道這塊，但是現在你知道了，面試被問到，你大概可以說一說。然後很多其他的候選人，也許還不如你，沒看過這個，被問到了壓根兒答不出來，相比之下，你還能說點出來，大概就是這個意思了。
如何保證訊息佇列的高可用
1 面試題 如何保證訊息佇列的高可用啊？2 面試官心理分析 如果有人問到你mq的知識，高可用是必問的，因為mq的缺點，我剛才已經說過了，有好多，導致系統可用性降低，等等。所以只要你用了mq，接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。要是你傻乎乎的就乾用了乙個mq，各種問題從來沒考慮...
如何保證訊息佇列的高可用
rabbitmq有三種模式 單機模式，普通集群模式，映象集群模式 單機模式就是在本地啟動自己玩，是demo級別的，在生產環境不會使用！普通集群模式 就是在多台機器上啟動多個rabbitmq例項，當建立乙個queue的時候，只會放在乙個例項上，但是每乙個例項都會同步queue的元資料，當進行消費的時候...
如何保證訊息佇列的高可用？（三）
rabbitmq是比較有代表性的，因為是基於主從做高可用性的。rabbitmq有三種模式 單機模式，普通集群模式，映象集群模式。就是demo級別的，一般就是你本地啟動了玩玩兒的，沒人生產用單機模式 這種方式確實很麻煩，也不怎麼好，沒做到所謂的分布式，就是個普通集群。因為這導致你要麼消費者每次隨機連線...