技術文章 » RabbitMQ 總結面試

RabbitMQ 總結面試

2020-08-12 11:36:45

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完全匹配。

  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. 完善訊息進行補償機制 機製

 

可靠性投遞保障方案

 

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

 

 

訊息的延遲投遞

 

 

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

 

 

多活模式：這種模式也是實現異地數據複製的主流模式，因爲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 ,虛擬路由器冗餘協定)來實現的。

 

在Keepalived服務正常工作時，主Master節點會不斷地向備節點發送( 多播的方式)心跳訊息，用以告訴備Backup節點自己還活看，當主Master節點發生故障時，就無法發送心跳訊息，備節點也就因此無法繼續檢測到來自主Master節點的心跳了，於是呼叫自身的接管程式，接管主Master節點的IP資源及服務。

 

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