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

2021-09-10 01:29:22 字數 2283 閱讀 1580

(1)rabbitmq的高可用性

rabbitmq是比較有代表性的,因為是基於高可用性的,以下是它的高可用性的實現。

1.普通集群模式

在多台機器上啟動多個rabbitmq例項,每個機器啟動乙個。但是你建立的queue只會放在乙個rabbitmq例項上,但是每個例項都同步queue的元資料。完了你消費的時候,實際上如果連線到了另外乙個例項,那麼那個例項會從queue所在例項上拉去資料過來。這種方式確實很麻煩,也不怎麼好,沒做到所謂的分布式,就是普通集群。因為這導致你要麼消費者每次隨機連線乙個例項然後拉取資料,要麼固定連線那個queue所在例項消費資料,前者有資料拉取的開銷,後者導致單例項效能瓶頸。

而且如果那個放queue的例項宕機了,會導致接下來其他例項就無法從那個例項拉取,如果你開啟了訊息持久化,讓rabbitmq落地儲存訊息的話,訊息不一定會丟失,得等這個例項恢復了,然後才可以繼續從這個queue拉取資料。所以這個情況就比較尷尬,沒有什麼所謂的高可用性可言,這個方案主要是提高吞吐量,就是說讓集群中多個節點來服務某個queue的讀寫操作。

2.映象集群模式

這種模式,才是所謂rabbitmq的高可用性,跟普通集群模式不一樣的是,你建立的queue,無論元資料還是queue裡的訊息都會存在於多個例項上,然後每次你寫訊息到queue的時候,都會自動把訊息到多個例項的queue裡進行訊息同步。

這樣的話,好處在於,任何乙個機器宕機,別的機器都可以使用。壞處在於,第一,效能開銷太大,訊息同步所有機器,導致網路頻寬壓力和消耗很重。第二,沒有擴充套件性而言,如果某個queue負載很重,我們加機器,新增的機器也包含了這個queue的所有資料,並沒有辦法線性擴充套件你的queue。

下面是如何開啟這個映象模式。

在後台新增乙個策略,這個策略是映象集群模式的策略,指定的時候可以要求資料同步到所有節點的,也可以要求就同步到指定數量的節點,然後你再次建立queue的時候,應用這個策略,就會自動將資料同步到其他的節點上去了。

(2)kafka的高可用性

首先我們對kafka有乙個基本的架構認識:多個broker組成,每個broker是乙個節點;你建立乙個topic,這個topic可以劃分為多個partition,每個partition可以存在於不同的broker上,每個partition就放一部分資料。

這就是天然的分布式訊息佇列,就是說乙個topic的資料,是分散放在多個機器上的,每個機器就放一部分資料。

實際上rabbitmq之類的,並不是分布式訊息佇列,他就是傳統的訊息佇列,只不過提供了一些集群、ha的機制而已,因為無論怎麼玩,rabbitmq乙個queue的資料都是放在乙個節點裡面的,映象集群下,也是每個節點都放這個queue的完整資料。

kafka0.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的時候,這個訊息才會被消費者讀到。

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

當前位置 home mq 如何保證訊息佇列高可用性?rabbitmq的高可用性 rabbitmq 是比較有代表性的,因為是基於主從 非分布式 做高可用性 三種模式 單機模式 普通集群模式 映象集群模式 單機模式 是demo級別 普通集群模式 無高可用性 再多台機器上啟動多個rabbitmq例項。每台...

HDFS如何保證高可用性

1 實現方式 namenode冗餘備份 2 具體過程 多個節點作為namenode,其中乙個處於active狀態,其它處於standby狀態。目前的實現有乙個條件,需要借助類似nfs這樣的分布式共享儲存系統,而且節點要能夠訪問這一系統。在active的namespace上的每個改變,需要同步到處於s...

如何保證MQ的高可用性?

1 面試題 如何保證訊息佇列的高可用啊?2 面試官心理分析 如果有人問到你mq的知識,高可用是必問的,因為mq的缺點,我剛才已經說過了,有好多,導致系統可用性降低,等等。所以只要你用了mq,接下來問的一些要點肯定就是圍繞著mq的那些缺點怎麼來解決了。要是你傻乎乎的就乾用了乙個mq,各種問題從來沒考慮...