世上最全的RabbitMQ-總結

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

AMQP協議

核心概念

1. server：又稱broker，接受客戶端鏈接，實現AMQP實體服務。
2. connection：鏈接和具體broker網絡鏈接。
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徹底匹配。

The default exchange is implicitly bound to every queue, with a routing key equal to the queue name. It is not possible to explicitly bind to, or unbind from the default exchange. It also cannot be deleted.

1. Toptic Exchange,是指發送到Topic Exchange的消息被轉發到全部關心的Routing key中指定topic的Queue上。Exchange 將routing key和某Topic進行模糊匹配，此時隊列須要綁定一個topic。所謂模糊匹配就是可使用通配符，「#」能夠匹配一個或多個詞，「」只匹配一個詞好比「log.#」能夠匹配「log.info.test」 "log. "就只能匹配log.error。
2. Fanout Exchange:不處理路由鍵，只需簡單的將隊列綁定到交換機上。發送到改交換機上的消息都會被髮送到與該交換機綁定的隊列上。Fanout轉發是最快的。

消息如何保證100％投遞

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

1. 保證消息的成功發出
2. 保證MQ節點節點的成功接收
3. 發送端MQ節點（broker）收到消息確認應答
4. 完善消息進行補償機制

可靠性投遞保障方案

1. 消息落庫，對消息進行打標
2. 消息的延遲投遞

在高併發場景下，每次進行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個節點）

1. 多活模式：這種模式也是實現異地數據複製的主流模式，由於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時鐘週期及內存帶寬

1. 藉助於Linux 2.6 (>= 2.6.27.19). 上的splice()系統調用，HAProxy能夠實現

零複製轉發(Zero-copy forwarding),在Linux 3.5及以上的OS中還能夠實現
心
零複製啓動(zero-starting)

1. 內存分配器在固定大小的內存池中可實現即時內存分配，這可以顯著減小創

建一個會話的時長

1. 樹型存儲:側重於使用做者多年前開發的彈性二叉樹，實現了以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 RouterRedundancy Protocol ,虛擬路由器冗餘協議)來實現的。在Keepalived服務正常工做時，主Master節點會不斷地向備節點發送( 多播的方式)心跳消息，用以告訴備Backup節點本身還活看，當主Master節點發生故障時，就沒法發送心跳消息，備節點也就所以沒法繼續檢測到來自主Master節點的心跳了，因而調用自身的接管程序，接管主Master節點的IP資源及服務。而當主Master節點恢復時備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色