户外AV丝袜网站_午夜福利国产精品_中文字幕在线高清乱码_国产高清特黄无遮挡大片_国产精品成人精品

如何保證消息隊列高可用性
時間:2019-11-22  瀏覽次數(shù):663

  如果有人問到你MQ的知識,高可用是必問的,因為MQ的缺點,我剛才已經(jīng)說過了,有好多,導致系統(tǒng)可用性降低,等等。所以只要你用了MQ,接下來問的一些要點肯定就是圍繞著MQ的那些缺點怎么來解決了。要是你傻乎乎的就干用了一個MQ,各種問題從來沒考慮過,那你就悲劇了,面試官對你的印象就是,只會簡單實用一些技術,沒任何思考,馬上對你的印象就不太好了。這樣的同學招進來要是做個20k薪資以內(nèi)的普通小弟還湊合。如果招進來做薪資20多k的高工,那就慘了,讓你設計個系統(tǒng),里面肯定一堆坑,出了事故公司受損失,團隊一起背鍋。

  這個問題這么問是很好的,因為不能問你kafka的高可用性怎么保證?ActiveMQ的高可用性怎么保證?一個面試官要是這么問就顯得很沒水平,人家可能用的就是RabbitMQ,沒用過Kafka,你上來問人家kafka干什么?這不是擺明了刁難人么。所以有水平的面試官,問的是MQ的高可用性怎么保證?這樣就是你用過哪個MQ,你就說說你對那個MQ的高可用性的理解。

  RabbitMQ是比較有代表性的,因為是基于主從做高可用性的,我們就以他為例子講解第一種MQ的高可用性怎么實現(xiàn)。

  2)普通集群模式:就是在多臺機器上啟動多個rabbitmq實例,每個機器啟動一個。但是你創(chuàng)建的queue,只會放在一個rabbtimq實例上,但是每個實例都同步queue的元數(shù)據(jù)。完了你消費的時候,實際上如果連接到了另外一個實例,那么那個實例會從queue所在實例上拉取數(shù)據(jù)過來。這種方式確實很麻煩,也不怎么好,沒做到所謂的分布式,就是個普通集群。因為這導致你要么消費者每次隨機連接一個實例然后拉取數(shù)據(jù),要么固定連接那個queue所在實例消費數(shù)據(jù),前者有數(shù)據(jù)拉取的開銷,后者導致單實例性能瓶頸。而且如果那個放queue的實例宕機了,會導致接下來其他實例就無法從那個實例拉取,如果你開啟了消息持久化,讓rabbitmq落地存儲消息的話,消息不一定會丟,得等這個實例恢復了,然后才可以繼續(xù)從這個queue拉取數(shù)據(jù)。所以這個事兒就比較尷尬了,這就沒有什么所謂的高可用性可言了,這方案主要是提高吞吐量的,就是說讓集群中多個節(jié)點來服務某個queue的讀寫操作。

  3)鏡像集群模式:這種模式,才是所謂的rabbitmq的高可用模式,跟普通集群模式不一樣的是,你創(chuàng)建的queue,無論元數(shù)據(jù)還是queue里的消息都會存在于多個實例上,然后每次你寫消息到queue的時候,都會自動把消息到多個實例的queue里進行消息同步。這樣的話,好處在于,你任何一個機器宕機了,沒事兒,別的機器都可以用。壞處在于,第一,這個性能開銷也太大了吧,消息同步所有機器,導致網(wǎng)絡帶寬壓力和消耗很重!第二,這么玩兒,就沒有擴展性可言了,如果某個queue負載很重,你加機器,新增的機器也包含了這個queue的所有數(shù)據(jù),并沒有辦法線性擴展你的queue。那么怎么開啟這個鏡像集群模式呢?我這里簡單說一下,避免面試人家問你你不知道,其實很簡單rabbitmq有很好的管理控制臺,就是在后臺新增一個策略,這個策略是鏡像集群模式的策略,指定的時候可以要求數(shù)據(jù)同步到所有節(jié)點的,也可以要求就同步到指定數(shù)量的節(jié)點,然后你再次創(chuàng)建queue的時候,應用這個策略,就會自動將數(shù)據(jù)同步到其他的節(jié)點上去了。

  1)kafka一個最基本的架構認識:多個broker組成,每個broker是一個節(jié)點;你創(chuàng)建一個topic,這個topic可以劃分為多個partition,每個partition可以存在于不同的broker上,每個partition就放一部分數(shù)據(jù)。這就是天然的分布式消息隊列,就是說一個topic的數(shù)據(jù),是分散放在多個機器上的,每個機器就放一部分數(shù)據(jù)。實際上rabbitmq之類的,并不是分布式消息隊列,他就是傳統(tǒng)的消息隊列,只不過提供了一些集群、HA的機制而已,因為無論怎么玩兒,rabbitmq一個queue的數(shù)據(jù)都是放在一個節(jié)點里的,鏡像集群下,也是每個節(jié)點都放這個queue的完整數(shù)據(jù)。

  2)kafka 0.8以前,是沒有HA機制的,就是任何一個broker宕機了,那個broker上的partition就廢了,沒法寫也沒法讀,沒有什么高可用性可言。kafka 0.8以后,提供了HA機制,就是replica副本機制。每個partition的數(shù)據(jù)都會同步到其它機器上,形成自己的多個replica副本。然后所有replica會選舉一個leader出來,那么生產(chǎn)和消費都跟這個leader打交道,然后其他replica就是follower。寫的時候,leader會負責把數(shù)據(jù)同步到所有follower上去,讀的時候就直接讀leader上數(shù)據(jù)即可。只能讀寫leader?很簡單,要是你可以隨意讀寫每個follower,那么就要care數(shù)據(jù)一致性的問題,系統(tǒng)復雜度太高,很容易出問題。kafka會均勻的將一個partition的所有replica分布在不同的機器上,這樣才可以提高容錯性。

  3)這么搞,就有所謂的高可用性了,因為如果某個broker宕機了,沒事兒,那個broker上面的partition在其他機器上都有副本的,如果這上面有某個partition的leader,那么此時會重新選舉一個新的leader出來,大家繼續(xù)讀寫那個新的leader即可。這就有所謂的高可用性了。

  寫數(shù)據(jù)的時候,生產(chǎn)者就寫leader,然后leader將數(shù)據(jù)落地寫本地磁盤,接著其他follower自己主動從leader來pull數(shù)據(jù)。一旦所有follower同步好數(shù)據(jù)了,就會發(fā)送ack給leader,leader收到所有follower的ack之后,就會返回寫成功的消息給生產(chǎn)者。(當然,這只是其中一種模式,還可以適當調(diào)整這個行為)

  消費的時候,只會從leader去讀,但是只有一個消息已經(jīng)被所有follower都同步成功返回ack的時候,這個消息才會被消費者讀到。




上一篇:網(wǎng)易有道 官方博客   下一篇:理上網(wǎng)來區(qū)塊鏈進入30時代山東如何把握機遇
推薦內(nèi)容