消息隊列如何做到高可用呢？-創(chuàng)新互聯(lián)

消息隊列在高并發(fā)的場景是必備技能，隨著我們的使用，在生產(chǎn)環(huán)境中的問題也是非常的多，比如：消息隊列如何做到高可用呢？

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網(wǎng)站設計、成都網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的昂昂溪網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

場景的中間件有很多種類型，在這里就準備常用的一些就用于分析處理。

1. RabbitMQ 的高可用性

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

RabbitMQ 有三種模式：單機模式、普通集群模式、鏡像集群模式。

單機模式

單機模式，就是 Demo 級別的，一般就是你本地啟動了玩玩兒的，沒人生產(chǎn)用單機模式。

普通集群模式（無高可用性）

普通集群模式，意思就是在多臺機器上啟動多個 RabbitMQ 實例，每個機器啟動一個。你創(chuàng)建的 queue，只會放在一個 RabbitMQ 實例上，但是每個實例都同步 queue 的元數(shù)據(jù)（元數(shù)據(jù)可以認為是 queue 的一些配置信息，通過元數(shù)據(jù)，可以找到 queue 所在實例）。

你消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從 queue 所在實例上拉取數(shù)據(jù)過來。

這種方式確實很麻煩，也不怎么好，沒做到所謂的分布式，就是個普通集群。因為這導致你要么消費者每次隨機連接一個實例然后拉取數(shù)據(jù)，要么固定連接那個 queue 所在實例消費數(shù)據(jù)，前者有數(shù)據(jù)拉取的開銷，后者導致單實例性能瓶頸。

而且如果那個放 queue 的實例宕機了，會導致接下來其他實例就無法從那個實例拉取，如果你開啟了消息持久化，讓 RabbitMQ 落地存儲消息的話，消息不一定會丟，得等這個實例恢復了，然后才可以繼續(xù)從這個 queue 拉取數(shù)據(jù)。

所以這個事兒就比較尷尬了，這就沒有什么所謂的高可用性，這方案主要是提高吞吐量的，就是說讓集群中多個節(jié)點來服務某個 queue 的讀寫操作。

鏡像集群模式（高可用性）

這種模式，才是所謂的 RabbitMQ 的高可用模式。跟普通集群模式不一樣的是，在鏡像集群模式下，你創(chuàng)建的 queue，無論元數(shù)據(jù)還是 queue 里的消息都會存在于多個實例上，就是說，每個 RabbitMQ 節(jié)點都有這個 queue 的一個完整鏡像，包含 queue 的全部數(shù)據(jù)的意思。然后每次你寫消息到 queue 的時候，都會自動把消息同步到多個實例的 queue 上。

那么如何開啟這個鏡像集群模式呢？其實很簡單，RabbitMQ 有很好的管理控制臺，就是在后臺新增一個策略，這個策略是鏡像集群模式的策略，指定的時候是可以要求數(shù)據(jù)同步到所有節(jié)點的，也可以要求同步到指定數(shù)量的節(jié)點，再次創(chuàng)建 queue 的時候，應用這個策略，就會自動將數(shù)據(jù)同步到其他的節(jié)點上去了。

這樣的話，好處在于，你任何一個機器宕機了，沒事兒，其它機器（節(jié)點）還包含了這個 queue 的完整數(shù)據(jù)，別的 consumer 都可以到其它節(jié)點上去消費數(shù)據(jù)。

壞處在于，第一，這個性能開銷也太大了吧，消息需要同步到所有機器上，導致網(wǎng)絡帶寬壓力和消耗很重！

第二，這些玩兒，不是分布式的，就沒有擴展性可言了，如果某個 queue 負載很重，你加機器，新增的機器也包含了這個 queue 的所有數(shù)據(jù)，并沒有辦法線性擴展你的 queue。

2. Kafka 的高可用性

Kafka 一個最基本的架構(gòu)認識：由多個 broker 組成，每個 broker 是一個節(jié)點；你創(chuàng)建一個 topic，這個 topic 可以劃分為多個 partition，每個 partition 可以存在于不同的 broker 上，每個 partition 就放一部分數(shù)據(jù)。

這就是天然的分布式消息隊列，就是說一個 topic 的數(shù)據(jù)，是分散放在多個機器上的，每個機器就放一部分數(shù)據(jù)。

實際上 RabbmitMQ 之類的，并不是分布式消息隊列，它就是傳統(tǒng)的消息隊列，只不過提供了一些集群、HA(High Availability, 高可用性) 的機制而已，因為無論怎么玩兒，RabbitMQ 一個 queue 的數(shù)據(jù)都是放在一個節(jié)點里的，鏡像集群下，也是每個節(jié)點都放這個 queue 的完整數(shù)據(jù)。

Kafka 0.8 以前，是沒有 HA 機制的，就是任何一個 broker 宕機了，那個 broker 上的 partition 就廢了，沒法寫也沒法讀，沒有什么高可用性可言。

比如說，我們假設創(chuàng)建了一個 topic，指定其 partition 數(shù)量是 3 個，分別在三臺機器上。但是，如果第二臺機器宕機了，會導致這個 topic 的 1/3 的數(shù)據(jù)就丟了，因此這個是做不到高可用的。

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 分布在不同的機器上，這樣才可以提高容錯性。

這么搞，就有所謂的高可用性了，因為如果某個 broker 宕機了，沒事兒，那個 broker上面的 partition 在其他機器上都有副本的。如果這個宕機的 broker 上面有某個 partition 的 leader，那么此時會從 follower 中重新選舉一個新的 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 的時候，這個消息才會被消費者讀到。

以上就是如何保證消息隊列的高可用？的詳細內(nèi)容，更多請關注創(chuàng)新互聯(lián)成都網(wǎng)站設計公司其它相關文章！

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

文章標題：消息隊列如何做到高可用呢？-創(chuàng)新互聯(lián)
文章出自：http://muchs.cn/article46/csppeg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App設計、營銷型網(wǎng)站建設、關鍵詞優(yōu)化、網(wǎng)站策劃、定制開發(fā)、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)