非常強(qiáng)悍的 RabbitMQ 總結(jié)，總結(jié)的很到位

RabbitMQ是基于AMQP協(xié)議的，通過(guò)使用通用協(xié)議就可以做到在不同語(yǔ)言之間傳遞。

AMQP協(xié)議

核心概念

1. server：又稱broker，接受客戶端連接，實(shí)現(xiàn)AMQP實(shí)體服務(wù)。

2. connection：連接和具體broker網(wǎng)絡(luò)連接。

3. channel：網(wǎng)絡(luò)信道，幾乎所有操作都在channel中進(jìn)行，channel是消息讀寫(xiě)的通道。客戶端可以建立多個(gè)channel，每個(gè)channel表示一個(gè)會(huì)話任務(wù)。

4. message：消息，服務(wù)器和應(yīng)用程序之間傳遞的數(shù)據(jù)，由properties和body組成。properties可以對(duì)消息進(jìn)行修飾，比如消息的優(yōu)先級(jí)，延遲等高級(jí)特性；body是消息實(shí)體內(nèi)容。

5. Virtual host：虛擬主機(jī)，用于邏輯隔離，最上層消息的路由。一個(gè)Virtual host可以若干個(gè)Exchange和Queue，同一個(gè)Virtual host不能有同名的Exchange或Queue。

6. Exchange：交換機(jī)，接受消息，根據(jù)路由鍵轉(zhuǎn)發(fā)消息到綁定的隊(duì)列上。

7. banding：Exchange和Queue之間的虛擬連接，binding中可以包括routing key

8. routing key：一個(gè)路由規(guī)則，虛擬機(jī)根據(jù)他來(lái)確定如何路由 一條消息。

9. Queue：消息隊(duì)列，用來(lái)存放消息的隊(duì)列。

交換機(jī)的類型，direct、topic、fanout、headers，durability（是否需要持久化true需要）auto delete當(dāng)最后一個(gè)綁定Exchange上的隊(duì)列被刪除Exchange也刪除。

1. Direct Exchange,所有發(fā)送到Direct Exchange的消息被轉(zhuǎn)發(fā)到RouteKey 中指定的Queue,Direct Exchange可以使用默認(rèn)的默認(rèn)的Exchange （default Exchange），默認(rèn)的Exchange會(huì)綁定所有的隊(duì)列，所以Direct可以直接使用Queue名（作為routing key ）綁定?；蛘呦M(fèi)者和生產(chǎn)者的routing key完全匹配。
2. Toptic Exchange,是指發(fā)送到Topic Exchange的消息被轉(zhuǎn)發(fā)到所有關(guān)心的Routing key中指定topic的Queue上。Exchange 將routing key和某Topic進(jìn)行模糊匹配，此時(shí)隊(duì)列需要綁定一個(gè)topic。所謂模糊匹配就是可以使用通配符，“#”可以匹配一個(gè)或多個(gè)詞，“”只匹配一個(gè)詞比如“l(fā)og.#”可以匹配“l(fā)og.info.test” log. 就只能匹配log.error。
3. Fanout Exchange:不處理路由鍵，只需簡(jiǎn)單的將隊(duì)列綁定到交換機(jī)上。發(fā)送到改交換機(jī)上的消息都會(huì)被發(fā)送到與該交換機(jī)綁定的隊(duì)列上。Fanout轉(zhuǎn)發(fā)是最快的。

消息如何保證100％投遞

什么是生產(chǎn)端的可靠性投遞？

1. 保證消息的成功發(fā)出
2. 保證MQ節(jié)點(diǎn)節(jié)點(diǎn)的成功接收
3. 發(fā)送端MQ節(jié)點(diǎn)（broker）收到消息確認(rèn)應(yīng)答
4. 完善消息進(jìn)行補(bǔ)償機(jī)制

可靠性投遞保障方案

消息落庫(kù)，對(duì)消息進(jìn)行打標(biāo)

消息的延遲投遞

在高并發(fā)場(chǎng)景下，每次進(jìn)行db的操作都是每場(chǎng)消耗性能的。我們使用延遲隊(duì)列來(lái)減少一次數(shù)據(jù)庫(kù)的操作。

消息冪等性

我對(duì)一個(gè)動(dòng)作進(jìn)行操作，我們肯能要執(zhí)行100次1000次，對(duì)于這1000次執(zhí)行的結(jié)果都必須一樣的。比如單線程方式下執(zhí)行update count-1的操作執(zhí)行一千次結(jié)果都是一樣的，所以這個(gè)更新操作就是一個(gè)冪等的，如果是在并發(fā)不做線程安全的處理的情況下update一千次操作結(jié)果可能就不是一樣的，所以并發(fā)情況下的update操作就不是一個(gè)冪等的操作。對(duì)應(yīng)到消息隊(duì)列上來(lái)，就是我們即使受到了多條一樣的消息，也和消費(fèi)一條消息效果是一樣的。

高并發(fā)的情況下如何避免消息重復(fù)消費(fèi)

1. 唯一id+加指紋碼，利用數(shù)據(jù)庫(kù)主鍵去重。
   優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
   缺點(diǎn)：高并發(fā)下有數(shù)據(jù)寫(xiě)入瓶頸。
2. 利用Redis的原子性來(lái)實(shí)習(xí)。
   使用Redis進(jìn)行冪等是需要考慮的問(wèn)題

• 是否進(jìn)行數(shù)據(jù)庫(kù)落庫(kù)，落庫(kù)后數(shù)據(jù)和緩存如何做到保證冪等（Redis ? 和數(shù)據(jù)庫(kù)如何同時(shí)成功同時(shí)失敗）？
• 如果不進(jìn)行落庫(kù)，都放在Redis中如何這是Redis和數(shù)據(jù)庫(kù)的同步策略？還有放在緩存中就能百分之百的成功嗎？

confirm 確認(rèn)消息、Return返回消息

理解confirm消息確認(rèn)機(jī)制

• 消息的確認(rèn)，指生產(chǎn)者收到投遞消息后，如果Broker收到消息就會(huì)給我們 ?的生產(chǎn)者一個(gè)應(yīng)答，生產(chǎn)者接受應(yīng)答來(lái)確認(rèn)broker是否收到消息。

如何實(shí)現(xiàn)confirm確認(rèn)消息。

• 在Channel上開(kāi)啟確認(rèn)模式：channel.confirmSelect()
• 在channel上添加監(jiān)聽(tīng)：addConfirmListener，監(jiān)聽(tīng)成功和失敗的結(jié)果，具體結(jié)果對(duì)消息進(jìn)行重新發(fā)送或者記錄日志。

return消息機(jī)制

Return消息機(jī)制處理一些不可路由的消息，我們的生產(chǎn)者通過(guò)指定一個(gè)Exchange和Routinkey，把消息送達(dá)到某一個(gè)隊(duì)列中去，然后我們消費(fèi)者監(jiān)聽(tīng)隊(duì)列進(jìn)行消費(fèi)處理！

在某些情況下，如果我們?cè)诎l(fā)送消息的時(shí)候當(dāng)Exchange不存在或者指定的路由key路由找不到，這個(gè)時(shí)候如果我們需要監(jiān)聽(tīng)這種不可到達(dá)的消息，就要使用Return Listener！

Mandatory 設(shè)置為true則會(huì)監(jiān)聽(tīng)器會(huì)接受到路由不可達(dá)的消息，然后處理。如果設(shè)置為false，broker將會(huì)自動(dòng)刪除該消息。

消費(fèi)端自定義監(jiān)聽(tīng)

消費(fèi)端限流

假設(shè)我們有個(gè)場(chǎng)景，首先，我們有個(gè)rabbitMQ服務(wù)器上有上萬(wàn)條消息未消費(fèi)，然后我們隨便打開(kāi)一個(gè)消費(fèi)者客戶端，會(huì)出現(xiàn)：巨量的消息瞬間推送過(guò)來(lái)，但是我們的消費(fèi)端無(wú)法同時(shí)處理這么多數(shù)據(jù)。

這時(shí)就會(huì)導(dǎo)致你的服務(wù)崩潰。其他情況也會(huì)出現(xiàn)問(wèn)題，比如你的生產(chǎn)者與消費(fèi)者能力不匹配，在高并發(fā)的情況下生產(chǎn)端產(chǎn)生大量消息，消費(fèi)端無(wú)法消費(fèi)那么多消息。

• rabbitMQ提供了一種qos（服務(wù)質(zhì)量保證）的功能，即非自動(dòng)確認(rèn)消息的前提下，如果有一定數(shù)目的消息（通過(guò)consumer或者Channel設(shè)置qos）未被確認(rèn)，不進(jìn)行新的消費(fèi)。

void basicQOS(unit prefetchSize,ushort prefetchCount,Boolean global)方法。

• prefetchSize:0 單條消息的大小限制。0就是不限制，一般都是不限制。
• prefetchCount: 設(shè)置一個(gè)固定的值，告訴rabbitMQ不要同時(shí)給一個(gè)消費(fèi)者推送多余N個(gè)消息，即一旦有N個(gè)消息還沒(méi)有ack，則consumer將block掉，直到有消息ack
• global：truefalse 是否將上面的設(shè)置用于channel，也是就是說(shuō)上面設(shè)置的限制是用于channel級(jí)別的還是consumer的級(jí)別的。

消費(fèi)端ack與重回隊(duì)列

• 消費(fèi)端進(jìn)行消費(fèi)的時(shí)候，如果由于業(yè)務(wù)異常我們可以進(jìn)行日志的記錄，然后進(jìn)行補(bǔ)償！（也可以加上最大努力次數(shù)的嘗試）
• 如果由于服務(wù)器宕機(jī)等嚴(yán)重問(wèn)題，那我們就需要手動(dòng)進(jìn)行ack保證消費(fèi)端的消費(fèi)成功！

消息重回隊(duì)列

• 重回隊(duì)列就是為了對(duì)沒(méi)有處理成功的消息，把消息重新投遞給broker！
• 實(shí)際應(yīng)用中一般都不開(kāi)啟重回隊(duì)列。

TTL隊(duì)列/消息

TTL time to live 生存時(shí)間。

• 支持消息的過(guò)期時(shí)間，在消息發(fā)送時(shí)可以指定。
• 支持隊(duì)列過(guò)期時(shí)間，在消息入隊(duì)列開(kāi)始計(jì)算時(shí)間，只要超過(guò)了隊(duì)列的超時(shí)時(shí)間配置，那么消息就會(huì)自動(dòng)的清除。

死信隊(duì)列

死信隊(duì)列：DLX，Dead-Letter-Exchange

利用DLX，當(dāng)消息在一個(gè)隊(duì)列中變成死信（dead message，就是沒(méi)有任何消費(fèi)者消費(fèi)）之后，他能被重新publish到另一個(gè)Exchange，這個(gè)Exchange就是DLX。

消息變?yōu)樗佬诺膸追N情況：

1. 消息被拒絕（basic.reject/basic.nack）同時(shí)requeue=false（不重回隊(duì)列）
2. TTL過(guò)期
3. 隊(duì)列達(dá)到最大長(zhǎng)度

DLX也是一個(gè)正常的Exchange，和一般的Exchange沒(méi)有任何的區(qū)別，他能在任何的隊(duì)列上被指定，實(shí)際上就是設(shè)置某個(gè)隊(duì)列的屬性。

當(dāng)這個(gè)隊(duì)列出現(xiàn)死信的時(shí)候，RabbitMQ就會(huì)自動(dòng)將這條消息重新發(fā)布到Exchange上去，進(jìn)而被路由到另一個(gè)隊(duì)列?？梢员O(jiān)聽(tīng)這個(gè)隊(duì)列中的消息作相應(yīng)的處理，這個(gè)特性可以彌補(bǔ)rabbitMQ以前支持的immediate參數(shù)的功能。

死信隊(duì)列的設(shè)置

• 設(shè)置Exchange和Queue，然后進(jìn)行綁定

Exchange: dlx.exchange(自定義的名字)

queue: dlx.queue（自定義的名字）

routingkey: #（#表示任何routingkey出現(xiàn)死信都會(huì)被路由過(guò)來(lái)）

然后正常的聲明交換機(jī)、隊(duì)列、綁定，只是我們?cè)陉?duì)列上加上一個(gè)參數(shù)：

arguments.put(x-dead-letter-exchange,dlx.exchange);

rabbitMQ集群模式

1. 主備模式：實(shí)現(xiàn)rabbitMQ高可用集群，一般在并發(fā)量和數(shù)據(jù)不大的情況下，這種模式好用簡(jiǎn)單。又稱warren模式。（區(qū)別于主從模式，主從模式主節(jié)點(diǎn)提供寫(xiě)操作，從節(jié)點(diǎn)提供讀操作，主備模式從節(jié)點(diǎn)不提供任何讀寫(xiě)操作，只做備份）如果主節(jié)點(diǎn)宕機(jī)備份從節(jié)點(diǎn)會(huì)自動(dòng)切換成主節(jié)點(diǎn)，提供服務(wù)。
2. 集群模式：經(jīng)典方式就是Mirror模式，保證100%數(shù)據(jù)不丟失，實(shí)現(xiàn)起來(lái)也是比較簡(jiǎn)單。

• 鏡像隊(duì)列，是rabbitMQ數(shù)據(jù)高可用的解決方案，主要是實(shí)現(xiàn)數(shù)據(jù)同步，一般來(lái)說(shuō)是由2-3節(jié)點(diǎn)實(shí)現(xiàn)數(shù)據(jù)同步，（對(duì)于100%消息可靠性解決方案一般是3個(gè)節(jié)點(diǎn)）

多活模式：這種模式也是實(shí)現(xiàn)異地?cái)?shù)據(jù)復(fù)制的主流模式，因?yàn)閟hovel模式配置相對(duì)復(fù)雜，所以一般來(lái)說(shuō)實(shí)現(xiàn)異地集群都是使用這種雙活，多活的模式，這種模式需要依賴rabbitMQ的federation插件，可以實(shí)現(xiàn)持續(xù)可靠的AMQP數(shù)據(jù)。

rabbitMQ部署架構(gòu)采用雙中心模式（多中心）在兩套（或多套）數(shù)據(jù)中心個(gè)部署一套rabbitMQ集群，各中心的rabbitMQ服務(wù)需要為提供正常的消息業(yè)務(wù)外，中心之間還需要實(shí)現(xiàn)部分隊(duì)列消息共享。

多活架構(gòu)如下：

federation插件是一個(gè)不需要構(gòu)建Cluster，而在Brokers之間傳輸消息的高性能插件，federation可以在brokers或者cluster之間傳輸消息，連接的雙方可以使用不同的users或者virtual host雙方也可以使用不同版本的erlang或者rabbitMQ版本。federation插件可以使用AMQP協(xié)議作為通訊協(xié)議，可以接受不連續(xù)的傳輸。

Federation Exchanges,可以看成Downstream從Upstream主動(dòng)拉取消息，但 ?
并不是拉取所有消息，必須是在Downstream上已經(jīng)明確定義Bindings關(guān)系的 ?
Exchange,也就是有實(shí)際的物理Queue來(lái)接收消息，才會(huì)從Upstream拉取消息 ?
到Downstream。

使用AMQP協(xié)議實(shí)施代理間通信，Downstream 會(huì)將綁定關(guān)系組合在一起， 綁定/解除綁定命令將發(fā)送到Upstream交換機(jī)。

因此，F(xiàn)ederation Exchange只接收具有訂閱的消息。

HAProxy是一款提供高可用性、負(fù)載均衡以及基于TCP (第四層)和HTTP ?
(第七層)應(yīng)用的代理軟件,支持虛擬主機(jī)，它是免費(fèi)、快速并且可靠的一種解決 ?
方案。

HAProxy特別適用于那些負(fù)載特大的web站點(diǎn)，這些站點(diǎn)通常又需要會(huì) ?
話保持或七層處理。HAProxy運(yùn)行在時(shí)下的硬件上，完全可以支持?jǐn)?shù)以萬(wàn)計(jì)的 ?
并發(fā)連接。

并且它的運(yùn)行模式使得它可以很簡(jiǎn)單安全的整合進(jìn)您當(dāng)前的架構(gòu)中 ?
同時(shí)可以保護(hù)你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上。

HAProxy性能為何這么好？

1. 單進(jìn)程、事件驅(qū)動(dòng)模型顯著降低了.上下文切換的開(kāi)銷及內(nèi)存占用.
2. 在任何可用的情況下，單緩沖(single buffering)機(jī)制能以不復(fù)制任何數(shù)據(jù)的方式完成讀寫(xiě)操作，這會(huì)節(jié)約大量的CPU時(shí)鐘周期及內(nèi)存帶寬
3. 借助于Linux 2.6 (>= 2.6.27.19). 上的splice()系統(tǒng)調(diào)用，HAProxy可以實(shí)現(xiàn)零復(fù)制轉(zhuǎn)發(fā)(Zero-copy forwarding),在Linux 3.5及以上的OS中還可以實(shí)現(xiàn)心零復(fù)制啟動(dòng)(zero-starting)
4. 內(nèi)存分配器在固定大小的內(nèi)存池中可實(shí)現(xiàn)即時(shí)內(nèi)存分配，這能夠顯著減少創(chuàng)建一個(gè)會(huì)話的時(shí)長(zhǎng)
5. 樹(shù)型存儲(chǔ):側(cè)重于使用作者多年前開(kāi)發(fā)的彈性二叉樹(shù)，實(shí)現(xiàn)了以O(shè)(log(N))的低開(kāi)銷來(lái)保持計(jì)時(shí)器命令、保持運(yùn)行隊(duì)列命令及管理輪詢及最少連接隊(duì)列

keepAlive

KeepAlived軟件主要是通過(guò)VRRP協(xié)議實(shí)現(xiàn)高可用功能的。VRRP是 ?
Virtual Router RedundancyProtocol(虛擬路由器冗余協(xié)議)的縮寫(xiě), ?
VRRP出現(xiàn)的目的就是為了解決靜態(tài)路由單點(diǎn)故障問(wèn)題的，它能夠保證當(dāng) ?
個(gè)別節(jié)點(diǎn)宕機(jī)時(shí)，整個(gè)網(wǎng)絡(luò)可以不間斷地運(yùn)行所以，Keepalived - -方面 ?
具有配置管理LVS的功能，同時(shí)還具有對(duì)LVS下面節(jié)點(diǎn)進(jìn)行健康檢查的功 ?
能，另一方面也可實(shí)現(xiàn)系統(tǒng)網(wǎng)絡(luò)服務(wù)的高可用功能

keepAlive的作用

1. 管理LVS負(fù)載均衡軟件
2. 實(shí)現(xiàn)LVS集群節(jié)點(diǎn)的健康檢查中
3. 作為系統(tǒng)網(wǎng)絡(luò)服務(wù)的高可用性(failover)

Keepalived如何實(shí)現(xiàn)高可用

Keepalived高可用服務(wù)對(duì)之間的故障切換轉(zhuǎn)移，是通過(guò)VRRP (Virtual Router ?
Redundancy Protocol ,虛擬路由器冗余協(xié)議)來(lái)實(shí)現(xiàn)的。

在Keepalived服務(wù)正常工作時(shí)，主Master節(jié)點(diǎn)會(huì)不斷地向備節(jié)點(diǎn)發(fā)送( 多播的方式)心跳消息，用以告訴備Backup節(jié)點(diǎn)自己還活看，當(dāng)主Master節(jié)點(diǎn)發(fā)生故障時(shí)，就無(wú)法發(fā)送心跳消息，備節(jié)點(diǎn)也就因此無(wú)法繼續(xù)檢測(cè)到來(lái)自主Master節(jié)點(diǎn)的心跳了，于是調(diào)用自身的接管程序，接管主Master節(jié)點(diǎn)的IP資源及服務(wù)。

而當(dāng)主Master節(jié)點(diǎn)恢復(fù)時(shí)備Backup節(jié)點(diǎn)又會(huì)釋放主節(jié)點(diǎn)故障時(shí)自身接管的IP資源及服務(wù)，恢復(fù)到原來(lái)的備用角色。

來(lái)源：segmentfault.com/a/1190000022387211

本文版權(quán)歸原作者所有，如有問(wèn)題請(qǐng)聯(lián)系我刪除。

感謝閱讀