很是強悍的 RabbitMQ 總結，寫得真好！

前言

RabbitMQ是基於AMQP協議的，經過使用通用協議就能夠作到在不一樣語言之間傳遞。

AMQP協議

核心概念

1. server：又稱broker，接受客戶端鏈接，實現AMQP實體服務。

2. connection：鏈接和具體broker網絡鏈接。整理了一份Java面試寶典完整版PDF已整理成文檔

3. channel：網絡信道，幾乎全部操做都在channel中進行，channel是消息讀寫的通道。客戶端能夠創建多個channel，每一個channel表示一個會話任務。

4. message：消息，服務器和應用程序之間傳遞的數據，由properties和body組成。properties能夠對消息進行修飾，好比消息的優先級，延遲等高級特性；body是消息實體內容。

5. Virtual host：虛擬主機，用於邏輯隔離，最上層消息的路由。一個Virtual host能夠若干個Exchange和Queue，同一個Virtual host不能有同名的Exchange或Queue。

6. Exchange：交換機，接受消息，根據路由鍵轉發消息到綁定的隊列上。

7. banding：Exchange和Queue之間的虛擬鏈接，binding中能夠包括routing key

8. routing key：一個路由規則，虛擬機根據他來肯定如何路由 一條消息。

9. Queue：消息隊列，用來存放消息的隊列。

Exchange

交換機的類型，direct、topic、fanout、headers，durability（是否須要持久化true須要）auto delete當最後一個綁定Exchange上的隊列被刪除Exchange也刪除。

1. Direct Exchange,全部發送到Direct Exchange的消息被轉發到RouteKey 中指定的Queue,Direct Exchange可使用默認的默認的Exchange （default Exchange），默認的Exchange會綁定全部的隊列，因此Direct能夠直接使用Queue名（做爲routing key ）綁定。或者消費者和生產者的routing key徹底匹配。

2. Toptic Exchange,是指發送到Topic Exchange的消息被轉發到全部關心的Routing key中指定topic的Queue上。Exchange 將routing key和某Topic進行模糊匹配，此時隊列須要綁定一個topic。所謂模糊匹配就是可使用通配符，「#」能夠匹配一個或多個詞，「」只匹配一個詞好比「log.#」能夠匹配「log.info.test」 "log. "就只能匹配log.error。

3. Fanout Exchange:不處理路由鍵，只需簡單的將隊列綁定到交換機上。發送到改交換機上的消息都會被髮送到與該交換機綁定的隊列上。Fanout轉發是最快的。

消息如何保證100％投遞

什麼是生產端的可靠性投遞？

1. 保證消息的成功發出

2. 保證MQ節點節點的成功接收

3. 發送端MQ節點（broker）收到消息確認應答

4. 完善消息進行補償機制

可靠性投遞保障方案

消息落庫，對消息進行打標

消息的延遲投遞整理了一份Java面試寶典完整版PDF已整理成文檔

在高併發場景下，每次進行db的操做都是每場消耗性能的。咱們使用延遲隊列來減小一次數據庫的操做。

消息冪等性

我對一個動做進行操做，咱們肯能要執行100次1000次，對於這1000次執行的結果都必須同樣的。好比單線程方式下執行update count-1的操做執行一千次結果都是同樣的，因此這個更新操做就是一個冪等的，若是是在併發不作線程安全的處理的狀況下update一千次操做結果可能就不是同樣的，因此併發狀況下的update操做就不是一個冪等的操做。對應到消息隊列上來，就是咱們即便受到了多條同樣的消息，也和消費一條消息效果是同樣的。

高併發的狀況下如何避免消息重複消費

1. 惟一id+加指紋碼，利用數據庫主鍵去重。 優勢：實現簡單 缺點：高併發下有數據寫入瓶頸。

2. 利用Redis的原子性來實習。 使用Redis進行冪等是須要考慮的問題

• 是否進行數據庫落庫，落庫後數據和緩存如何作到保證冪等（Redis 和數據庫如何同時成功同時失敗）？

• 若是不進行落庫，都放在Redis中如何這是Redis和數據庫的同步策略？還有放在緩存中就能百分之百的成功嗎？

confirm 確認消息、Return返回消息

理解confirm消息確認機制

• 消息的確認，指生產者收到投遞消息後，若是Broker收到消息就會給咱們 的生產者一個應答，生產者接受應答來確認broker是否收到消息。

如何實現confirm確認消息。

• 在Channel上開啓確認模式：channel.confirmSelect()

• 在channel上添加監聽：addConfirmListener，監聽成功和失敗的結果，具體結果對消息進行從新發送或者記錄日誌。

return消息機制

Return消息機制處理一些不可路由的消息，咱們的生產者經過指定一個Exchange和Routinkey，把消息送達到某一個隊列中去，而後咱們消費者監聽隊列進行消費處理！

在某些狀況下，若是咱們在發送消息的時候當Exchange不存在或者指定的路由key路由找不到，這個時候若是咱們須要監聽這種不可到達的消息，就要使用Return Listener！

Mandatory 設置爲true則會監聽器會接受到路由不可達的消息，而後處理。若是設置爲false，broker將會自動刪除該消息。

消費端自定義監聽

消費端限流

假設咱們有個場景，首先，咱們有個rabbitMQ服務器上有上萬條消息未消費，而後咱們隨便打開一個消費者客戶端，會出現：巨量的消息瞬間推送過來，可是咱們的消費端沒法同時處理這麼多數據。

這時就會致使你的服務崩潰。其餘狀況也會出現問題，好比你的生產者與消費者能力不匹配，在高併發的狀況下生產端產生大量消息，消費端沒法消費那麼多消息。

• rabbitMQ提供了一種qos（服務質量保證）的功能，即非自動確認消息的前提下，若是有必定數目的消息（經過consumer或者Channel設置qos）未被確認，不進行新的消費。

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

• prefetchSize:0 單條消息的大小限制。0就是不限制，通常都是不限制。

• prefetchCount: 設置一個固定的值，告訴rabbitMQ不要同時給一個消費者推送多餘N個消息，即一旦有N個消息尚未ack，則consumer將block掉，直到有消息ack

• global：truefalse 是否將上面的設置用於channel，也是就是說上面設置的限制是用於channel級別的仍是consumer的級別的。

消費端ack與重回隊列

• 消費端進行消費的時候，若是因爲業務異常咱們能夠進行日誌的記錄，而後進行補償！（也能夠加上最大努力次數的嘗試）

• 若是因爲服務器宕機等嚴重問題，那咱們就須要手動進行ack保證消費端的消費成功！

消息重回隊列

• 重回隊列就是爲了對沒有處理成功的消息，把消息從新投遞給broker！

• 實際應用中通常都不開啓重回隊列。

TTL隊列/消息

TTL time to live 生存時間。

• 支持消息的過時時間，在消息發送時能夠指定。

• 支持隊列過時時間，在消息入隊列開始計算時間，只要超過了隊列的超時時間配置，那麼消息就會自動的清除。

死信隊列

死信隊列：DLX，Dead-Letter-Exchange

利用DLX，當消息在一個隊列中變成死信（dead message，就是沒有任何消費者消費）以後，他能被從新publish到另外一個Exchange，這個Exchange就是DLX。

消息變爲死信的幾種狀況：

1. 消息被拒絕（basic.reject/basic.nack）同時requeue=false（不重回隊列）

2. TTL過時

3. 隊列達到最大長度

DLX也是一個正常的Exchange，和通常的Exchange沒有任何的區別，他能在任何的隊列上被指定，實際上就是設置某個隊列的屬性。 當這個隊列出現死信的時候，RabbitMQ就會自動將這條消息從新發布到Exchange上去，進而被路由到另外一個隊列。能夠監聽這個隊列中的消息做相應的處理，這個特性能夠彌補rabbitMQ之前支持的immediate參數的功能。

死信隊列的設置

• 設置Exchange和Queue，而後進行綁定

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

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

routingkey: #（#表示任何routingkey出現死信都會被路由過來）

而後正常的聲明交換機、隊列、綁定，只是咱們在隊列上加上一個參數：

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

rabbitMQ集羣模式

1. 主備模式：實現rabbitMQ高可用集羣，通常在併發量和數據不大的狀況下，這種模式好用簡單。又稱warren模式。（區別於主從模式，主從模式主節點提供寫操做，從節點提供讀操做，主備模式從節點不提供任何讀寫操做，只作備份）若是主節點宕機備份從節點會自動切換成主節點，提供服務。

2. 集羣模式：經典方式就是Mirror模式，保證100%數據不丟失，實現起來也是比較簡單。

• 鏡像隊列，是rabbitMQ數據高可用的解決方案，主要是實現數據同步，通常來講是由2-3節點實現數據同步，（對於100%消息可靠性解決方案通常是3個節點）整理了一份Java面試寶典完整版PDF已整理成文檔

多活模式：這種模式也是實現異地數據複製的主流模式，由於shovel模式配置相對複雜，因此通常來講實現異地集羣都是使用這種雙活，多活的模式，這種模式須要依賴rabbitMQ的federation插件，能夠實現持續可靠的AMQP數據。

rabbitMQ部署架構採用雙中心模式（多中心）在兩套（或多套）數據中心個部署一套rabbitMQ集羣，各中心的rabbitMQ服務須要爲提供正常的消息業務外，中心之間還須要實現部分隊列消息共享。

多活架構以下：

federation插件是一個不須要構建Cluster，而在Brokers之間傳輸消息的高性能插件，federation能夠在brokers或者cluster之間傳輸消息，鏈接的雙方可使用不一樣的users或者virtual host雙方也可使用不一樣版本的erlang或者rabbitMQ版本。federation插件可使用AMQP協議做爲通信協議，能夠接受不連續的傳輸。

Federation Exchanges,能夠當作Downstream從Upstream主動拉取消息，但 並非拉取全部消息，必須是在Downstream上已經明肯定義Bindings關係的 Exchange,也就是有實際的物理Queue來接收消息，纔會從Upstream拉取消息 到Downstream。

使用AMQP協議實施代理間通訊，Downstream 會將綁定關係組合在一塊兒， 綁定/解除綁定命令將發送到Upstream交換機。

所以，Federation Exchange只接收具備訂閱的消息。

HAProxy是一款提供高可用性、負載均衡以及基於TCP (第四層)和HTTP (第七層)應用的代理軟件,支持虛擬主機，它是免費、快速而且可靠的一種解決 方案。 HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會 話保持或七層處理。HAProxy運行在時下的硬件上，徹底能夠支持數以萬計的 併發鏈接。 而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中 同時能夠保護你的web服務器不被暴露到網絡上。

HAProxy性能爲什麼這麼好？

1. 單進程、事件驅動模型顯著下降了.上下文切換的開銷及內存佔用.

2. 在任何可用的狀況下，單緩衝(single buffering)機制能以不復制任何數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬

3. 藉助於Linux 2.6 (>= 2.6.27.19). 上的splice()系統調用，HAProxy能夠實現零複製轉發(Zero-copy forwarding),在Linux 3.5及以上的OS中還能夠實現心零複製啓動(zero-starting)

4. 內存分配器在固定大小的內存池中可實現即時內存分配，這可以顯著減小建立一個會話的時長

5. 樹型存儲:側重於使用做者多年前開發的彈性二叉樹，實現了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少鏈接隊列

keepAlive

KeepAlived軟件主要是經過VRRP協議實現高可用功能的。VRRP是 Virtual Router RedundancyProtocol(虛擬路由器冗餘協議)的縮寫, VRRP出現的目的就是爲了解決靜態路由單點故障問題的，它可以保證當 個別節點宕機時，整個網絡能夠不間斷地運行因此，Keepalived - -方面 具備配置管理LVS的功能，同時還具備對LVS下面節點進行健康檢查的功 能，另外一方面也可實現系統網絡服務的高可用功能

keepAlive的做用

1. 管理LVS負載均衡軟件

2. 實現LVS集羣節點的健康檢查中

3. 做爲系統網絡服務的高可用性(failover)

Keepalived如何實現高可用

Keepalived高可用服務對之間的故障切換轉移，是經過VRRP (Virtual Router Redundancy Protocol ,虛擬路由器冗餘協議)來實現的。整理了一份Java面試寶典完整版PDF已整理成文檔

在Keepalived服務正常工做時，主Master節點會不斷地向備節點發送( 多播的方式)心跳消息，用以告訴備Backup節點本身還活看，當主Master節點發生故障時，就沒法發送心跳消息，備節點也就所以沒法繼續檢測到來自主Master節點的心跳了，因而調用自身的接管程序，接管主Master節點的IP資源及服務。

而當主Master節點恢復時備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。