03 引入訊息佇列之後該如何保證其高可用性?

2021-09-08 12:46:12 字數 3543 閱讀 4748

目錄

1、面試題

2、面試官心理分析

3、面試題剖析

(1)rabbitmq的高可用性

(2)kafka的高可用性

如何保證訊息佇列的高可用啊?

如果有人問到你mq的知識,高可用是必問的,因為mq的缺點,我剛才已經說過了,有好多,導致系統可用性降低,等等。所以只要你用了mq,接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。

要是你傻乎乎的就乾用了乙個mq,各種問題從來沒考慮過,那你就杯具了,面試官對你的印象就是,只會簡單實用一些技術,沒任何思考,馬上對你的印象就不太好了。這樣的同學招進來要是做個20k薪資以內的普通小弟還湊合。如果招進來做薪資20多k的高工,那就慘了,讓你設計個系統,裡面肯定一堆坑,出了事故公司受損失,團隊一起背鍋。

去年的事兒,非常大的網際網路公司,非常核心的系統,就是疏忽了mq,沒考慮mq如何保證高可用,如果mq掛了怎麼辦,導致幾個小時系統不可用,公司損失幾千萬,team背鍋,你鬧的禍,你老大幫你一起背鍋

這個問題這麼問是很好的,因為不能問你kafka的高可用性怎麼保證啊?activemq的高可用性怎麼保證啊?乙個面試官要是這麼問就顯得很沒水平,人家可能用的就是rabbitmq,沒用過kafka,你上來問人家kafka幹什麼?這不是擺明了刁難人麼。

所以有水平的面試官,問的是mq的高可用性怎麼保證?這樣就是你用過哪個mq,你就說說你對那個mq的高可用性的理解。

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,你是沒那麼多時間的。你只能確保,你之前也許壓根兒不知道這塊,但是現在你知道了,面試被問到,你大概可以說一說。然後很多其他的候選人,也許還不如你,沒看過這個,被問到了壓根兒答不出來,相比之下,你還能說點出來,大概就是這個意思了。

訊息佇列二 引入訊息佇列後怎麼保證高可用

問到你mq的知識,高可用是必問的,因為mq的缺點,我剛才已經說過了,有好多,導致系統可用性降低,等等。所以只要你用了mq,接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。要是你傻乎乎的就乾用了乙個mq,各種問題從來沒考慮過,那你就杯具了,面試官對你的印象就是,只會簡單實用一些技術,沒任何...

再讀《精通css》03 引入和注釋

2 在css中也可以匯入其他css。但匯入規則要放在文件的最前面。而且要避免兩層以上的匯入。3 因為先考慮匯入的樣式表,在考慮鏈結的樣式表,所以鏈結的樣式表會覆蓋掉匯入的。4 對 進行注釋是個好習慣,css採用c風格的注釋 我總覺得在注視單行的時候,這種方法有點麻煩 5 在文件頭部應該加上文件作用,...

引入訊息佇列以後如何保證訊息佇列的高可用

rabbitmq的高可用 rabbitmq是比較有代表性的,因為是基於主從做高可用性的,我們就以他為例子講解第一種mq的高可用性怎麼實現。rabbitmq有三種模式 單機模式,普通集群模式,映象集群模式 1 單機模式 就是demo級別的,一般就是你本地啟動了玩玩兒的,沒人生產用單機模式 2 普通集群...