手擼架構，RabbitMQ 面試49問

MQ如何選型？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
客戶端支持語言	JAVA、C、C++、Python、PHP、Pert、net等	官方支持Erlang、Java/Ruby等，社區產出多種語言API，幾乎支持所有常用語言	JAVA、C++（不成熟）	官方支持JAVA,開源社區有多語言版本，如PHP,Python,GO,C/C++，Ruby，NodeJS等編程語言
單機吞吐量	萬級，吞吐量RocketMQ和Kafka要低了一個數量級	萬級，吞吐量比RocketMQ和Kafka要低了一個數量級	10萬級，RocketMQ也是可以支撐高吞吐的一種MQ	10萬級別，這是kafka最大的優點，就是吞吐量高， 一般配合大資料類的系統來進行實時資料計算、日志采集等場景
topic數量對吞吐量的影響			topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降 這是RocketMQ的一大優勢，在同等機器下，可以支撐大量的topic	topic從幾十個到幾百個的時候，吞吐量會大幅度下降 所以在同等機器下，kafka盡量保證topic數量不要過多，如果要支撐大規模topic，需要增加更多的機器資源
時效性	ms級	微秒級，這是rabbitmq的一大特點，延遲是最低的	ms級	延遲在ms級以內
可用性	高，基于主從架構實作高可用性	高，基于主從架構實作高可用性	非常高，分布式架構	非常高，kafka是分布式的，一個資料多個副本，少數機器宕機，不會丟失資料，不會導致不可用
訊息可靠性	有較低的概率丟失資料		經過引數優化配置，可以做到0丟失	經過引數優化配置，訊息可以做到0丟失
持久化	記憶體、檔案、資料庫	記憶體、檔案，支持資料堆積，但資料堆積會影響生產速率	磁盤檔案	磁盤檔案，只要磁盤容量足夠，可以做到無限訊息堆積
功能支持	MQ領域的功能極其完備	基于erlang開發，所以并發能力很強，性能極其好，延時很低	MQ功能較為完善，還是分布式的，擴展性好	功能較為簡單，主要支持簡單的MQ功能，在大資料領域的實時計算以及日志采集被大規模使用，是事實上的標準

RabbitMQ是什么？

RabbitMQ是實作了高級訊息佇列協議（AMQP）的開源訊息代理軟體（亦稱面向訊息的中間件），RabbitMQ服務器是用Erlang語言撰寫的，而群集和故障轉移是構建在開放電信平臺框架上的，所有主要的編程語言均有與代理介面通訊的客戶端庫，

RabbitMQ特點

可靠性: RabbitMQ使用一些機制來保證可靠性， 如持久化、傳輸確認及發布確認等，

靈活的路由 : 在訊息進入佇列之前，通過交換器來路由訊息，對于典型的路由功能， RabbitMQ 己經提供了一些內置的交換器來實作，針對更復雜的路由功能，可以將多個 交換器系結在一起， 也可以通過插件機制來實作自己的交換器，

擴展性: 多個RabbitMQ節點可以組成一個集群，也可以根據實際業務情況動態地擴展 集群中節點，

高可用性 : 佇列可以在集群中的機器上設定鏡像，使得在部分節點出現問題的情況下隊 列仍然可用，

多種協議: RabbitMQ除了原生支持AMQP協議，還支持STOMP， MQTT等多種訊息 中間件協議，

多語言客戶端 :RabbitMQ 幾乎支持所有常用語言，比如 Java、 Python、 Ruby、 PHP、 C#、 JavaScript 等，

管理界面 : RabbitMQ 提供了一個易用的用戶界面，使得用戶可以監控和管理訊息、集 群中的節點等，

令插件機制 : RabbitMQ 提供了許多插件 ， 以實作從多方面進行擴展，當然也可以撰寫自 己的插件，

AMQP是什么

RabbitMQ就是 AMQP 協議的 Erlang 的實作(當然 RabbitMQ 還支持 STOMP2、 MQTT3 等協議 ) AMQP 的模型架構 和 RabbitMQ 的模型架構是一樣的，生產者將訊息發送給交換器，交換器和佇列系結 ，

RabbitMQ 中的交換器、交換器型別、佇列、系結、路由鍵等都是遵循的 AMQP 協議中相 應的概念，目前 RabbitMQ 最新版本默認支持的是 AMQP 0-9-1，

AMQP協議3層

Module Layer:協議最高層，主要定義了一些客戶端呼叫的命令，客戶端可以用這些命令實作自己的業務邏輯，

Session Layer:中間層，主要負責客戶端命令發送給服務器，再將服務端應答回傳客戶端，提供可靠性同步機制和錯誤處理，

TransportLayer:最底層，主要傳輸二進制資料流，提供幀的處理、信道服用、錯誤檢測和資料表示等，

AMQP模型的幾大組件

• 交換器 (Exchange)：訊息代理服務器中用于把訊息路由到佇列的組件，

• 佇列 (Queue)：用來存盤訊息的資料結構，位于硬碟或記憶體中，

• 系結 (Binding)：一套規則，告知交換器訊息應該將訊息投遞給哪個佇列，

RocketMq的訊息是有序的嗎？

一個topic下有多個queue，為了保證發送有序，rocketmq提供了MessageQueueSelector佇列選擇機制

1. 可使用hash取模法,讓同一個訂單發送到同一個queue中，再使用同步發送，只有訊息A發送成功，再發送訊息B
2. rocketmq的topic內的佇列機制，可以保證存盤滿足FIFO，剩下的只需要消費者順序消費即可
3. rocketmq僅保證順序發送，順序消費由消費者業務保證

RocketMq事務訊息的實作機制？

RocketMQ第一階段發送Prepared訊息時，會拿到訊息的地址

RocketMQ第二階段執行本地事物，第三階段通過第一階段拿到的地址去訪問訊息，并修改訊息的狀態，

RocketMQ會定期掃描訊息集群中的事物訊息，如果發現了Prepared訊息，它會向訊息發送端(生產者)確認，RocketMQ會根據發送端設定的策略來決定是回滾還是繼續發送確認訊息，這樣就保證了訊息發送與本地事務同時成功或同時失敗，

訊息如何分發？

若該佇列?少有?個消費者訂閱，訊息將以回圈（round-robin）的?式發送給消費者，每條訊息只會分發給?個訂閱的消費者（前提是消費者能夠正常處理訊息并進?確認），

RabbitMQ routing 路由模式

1、 訊息生產者將訊息發送給交換機按照路由判斷,路由是字串(info) 當前產生的訊息攜帶路由字符(物件的方法)，交換機根據路由的 key，只能匹配上路由 key 對應的訊息佇列,對應的消費者才能消費訊息，

2、 根據業務功能定義路由字串，

3、 從系統的代碼邏輯中獲取對應的功能字串,將訊息任務扔到對應的佇列中，

4、 業務場景：error 通知、EXCEPTION、錯誤通知的功能、傳統意義的錯誤通知、客戶通知、利用 key 路由，可以將程式中的錯誤封裝成訊息傳入到訊息佇列中，開發者可以自定義消費者，實時接收錯誤，

訊息怎么路由？

訊息提供方->路由->一至多個佇列訊息發布到交換器時，訊息將擁有一個路由鍵（routing key），在訊息創建時設定，通過佇列路由鍵，可以把佇列系結到交換器上，訊息到達交換器后，RabbitMQ 會將訊息的路由鍵與佇列的路由鍵進行匹配（針對不同的交換器有不同的路由規則），

常用的交換器主要分為一下三種：

• fanout：如果交換器收到訊息，將會廣播到所有系結的佇列上，
• direct：如果路由鍵完全匹配，訊息就被投遞到相應的佇列，
• topic：可以使來自不同源頭的訊息能夠到達同一個佇列， 使用 topic 交換器時，可以使用通配符，

RabbitMQ publish/subscribe 發布訂閱(共享資源)

每個消費者監聽自己的佇列，

生產者將訊息發給 broker，由交換機將訊息轉發到系結此交換機的每個佇列，每個系結交換機的佇列都將接收到訊息，

RabbitMQ 中的 broker 是指什么？cluster 又是指什么？

broker 是指一個或多個 erlang node 的邏輯分組，且 node 上運行著 RabbitMQ 應用程式，

cluster 是在 broker 的基礎之上，增加了 node 之間共享元資料的約束，

什么是元資料？元資料分為哪些型別？包括哪些內容？與 cluster 相關的元資料有哪些？

在非 cluster 模式下，元資料主要分為：

Queue 元資料（queue 名字和屬性等）

Exchange 元資料（exchange 名字、型別和屬性等）

Binding 元資料（存放路由關系的查找表）

Vhost 元資料（vhost 范圍內針對前三者的名字空間約束和安全屬性設定）

在cluster 模式下，還包括： cluster 中 node 位置資訊和 node 關系資訊，

元資料是如何保存的？

元資料按照 erlangnode 的型別確定是僅保存于 RAM 中，還是同時保存在 RAM 和 disk 上，

元資料在 cluster 中是如何分布的？

元資料在cluster 中是全 node 分布的，

RAM node 和 disk node 的區別？

RAM node 僅將 fabric（即 queue、exchange 和 binding 等 RabbitMQ 基礎構件）相關元資料保存到記憶體中，但 disk node 會在記憶體和磁盤中均進行存盤，RAM node 上唯一會存盤到磁盤上的元資料是 cluster 中使用的 disk node 的地址，要求在 RabbitMQ cluster中至少存在一個 disk node

RabbitMQ 上的一個 queue 中存放的 message 是否有數量限制？

可以認為是無限制，因為限制取決于機器的記憶體，但是訊息過多會導致處理效率的下降，

RabbitMQ 概念里的 channel、exchange 和 queue 是邏輯概念，還是對應著行程物體？分別起什么作用？

queue 具有自己的 erlang 行程；

exchange 內部實作為保存 binding 關系的查找表；

channel 是實際進行路由作業的物體，即負責按照 routing_key 將 message 投遞給queue ，

由 AMQP 協議描述可知，channel 是真實 TCP 連接之上的虛擬連接，所有AMQP 命令都是通過 channel 發送的，且每一個 channel 有唯一的 ID，一個 channel 只能被單獨一個作業系統執行緒使用，故投遞到特定 channel 上的 message 是有順序的，但一個作業系統執行緒上允許使用多個 channel ，channel 號為 0 的 channel 用于處理所有對于當前 connection 全域有效的幀，而 1-65535 號 channel 用于處理和特定 channel 相關的幀，其中每一個 channel 運行在一個獨立的執行緒上，多執行緒共享同一個 socket，

vhost 是什么？起什么作用？

vhost 可以理解為虛擬 broker ，即 mini-RabbitMQ server，其內部均含有獨立的queue、exchange 和 binding 等，但最最重要的是，其擁有獨立的權限系統，可以做到vhost 范圍的用戶控制，當然，從 RabbitMQ 的全域角度，vhost 可以作為不同權限隔離的手段（一個典型的例子就是不同的應用可以跑在不同的 vhost 中），

若 cluster 中擁有某個 queue 的 owner node 失效了，且該 queue 被宣告具有durable 屬性，是否能夠成功從其他 node 上重新宣告該 queue ？

不能，在這種情況下，將得到 404 NOT_FOUND 錯誤，只能等 queue 所屬的 node恢復后才能使用該 queue ，但若該 queue 本身不具有 durable 屬性，則可在其他 node上重新宣告，

cluster 中 node 的失效會對 consumer 產生什么影響？若是在 cluster 中創建了mirrored queue ，這時 node 失效會對 consumer 產生什么影響？

若是 consumer 所連接的那個 node 失效（無論該 node 是否為 consumer 所訂閱queue 的 owner node），則 consumer 會在發現 TCP 連接斷開時，按標準行為執行重連邏輯，并根據“Assume Nothing”原則重建相應的 fabric 即可，若是失效的 node 為consumer 訂閱 queue 的 owner node，則 consumer 只能通過 Consumer CancellationNotification 機制來檢測與該 queue 訂閱關系的終止，否則會出現傻等卻沒有任何訊息來到的問題，

能夠在地理上分開的不同資料中心使用 RabbitMQ cluster 么？

不能，第一，你無法控制所創建的 queue 實際分布在 cluster 里的哪個 node 上（一般使用 HAProxy + cluster 模型時都是這樣），這可能會導致各種跨地域訪問時的常見問題；

第二，Erlang 的 OTP 通信框架對延遲的容忍度有限，這可能會觸發各種超時，導致業務疲于處理；

第三，在廣域網上的連接失效問題將導致經典的“腦裂”問題，而RabbitMQ 目前無法處理（該問題主要是說 Mnesia），

為什么 heavy RPC 的使用場景下不建議采用 disk node ？

heavy RPC 是指在業務邏輯中高頻呼叫 RabbitMQ 提供的 RPC 機制，導致不斷創建、銷毀 reply queue ，進而造成 disk node 的性能問題（因為會針對元資料不斷寫盤），所以在使用 RPC 機制時需要考慮自身的業務場景，

向不存在的 exchange 發 publish 訊息會發生什么？向不存在的 queue 執行consume 動作會發生什么？

都會收到 Channel.Close 信令告之不存在（內含原因 404 NOT_FOUND），

routing_key 和 binding_key 的最大長度是多少？

255 位元組，

RabbitMQ 允許發送的 message 最大可達多大？

根據 AMQP 協議規定，訊息體的大小由 64-bit 的值來指定，所以你就可以知道到底能發多大的資料了，

什么情況下 producer 不主動創建 queue 是安全的？

1.message 是允許丟失的；

2.實作了針對未處理訊息的 republish 功能（例如采用Publisher Confirm 機制），

如何確保訊息不丟失？

訊息持久化的前提是：將交換器/佇列的durable屬性設定為true，表示交換器/佇列是持久交換器/佇列，在服務器崩潰或重啟之后不需要重新創建交換器/佇列（交換器/佇列會?動創建），

如果訊息想要從Rabbit崩潰中恢復，那么訊息必須：

1、在訊息發布前，通過把它的 “投遞模式” 選項設定為2（持久）來把訊息標記成持久化

2、將訊息發送到持久交換器

3、訊息到達持久佇列

如何避免訊息重復投遞或重復消費？

在訊息生產時，MQ內部針對每條生產者發送的訊息生成一個inner-msg-id，作為去重和冪等的依據（訊息投遞失敗并重傳），避免重復的訊息進入佇列；在訊息消費時，要求訊息體中必須要有一個bizId（對于同一業務全域唯一，如支付ID、訂單ID、帖子ID等）作為去重和冪等的依據，避免同一條訊息被重復消費，

如何保證訊息佇列高可用？

1.集群:

集群可以擴展訊息通信的吞吐量，但是不會備份訊息，備份訊息要通過鏡像佇列的方式解決，

佇列存盤在單個節點、交換器存盤在所有節點

2.鏡像佇列:

將需要消費的佇列變為鏡像佇列，存在于多個節點，這樣就可以實作 RabbitmQ的HA高可用性，作用就是訊息物體會主動在鏡像節點之間實作同步，而不是像普通模式那樣，在εoηsuwεκ消費資料時臨時讀取，缺點就是，集群內部的同步通訊會占用大量的網路帶寬，

使?RabbitMQ增加rest服務吞吐量

“dead letter”queue 的用途？

當訊息被 RabbitMQ server 投遞到 consumer 后，但 consumer 卻通過 Basic.Reject進行了拒絕時（同時設定 requeue=false），那么該訊息會被放入“dead letter”queue 中，該 queue 可用于排查 message 被 reject 或 undeliver 的原因，

為什么說保證 message 被可靠持久化的條件是 queue 和 exchange 具有durable 屬性，同時 message 具有 persistent 屬性才行？

binding 關系可以表示為 exchange – binding – queue ，從檔案中我們知道，若要求投遞的 message 能夠不丟失，要求 message 本身設定 persistent 屬性，要求 exchange和 queue 都設定 durable 屬性，其實這問題可以這么想，若 exchange 或 queue 未設定durable 屬性，則在其 crash 之后就會無法恢復，那么即使 message 設定了 persistent 屬性，仍然存在 message 雖然能恢復但卻無處容身的問題；同理，若 message 本身未設定persistent 屬性，則 message 的持久化更無從談起，

Consumer Cancellation Notification 機制用于什么場景？

用于保證當鏡像 queue 中 master 掛掉時，連接到 slave 上的 consumer 可以收到自身 consume 被取消的通知，進而可以重新執行 consume 動作從新選出的 master 出獲得訊息，若不采用該機制，連接到 slave 上的 consumer 將不會感知 master 掛掉這個事情，導致后續無法再收到新 master 廣播出來的 message ，另外，因為在鏡像 queue 模式下，存在將 message 進行 requeue 的可能，所以實作 consumer 的邏輯時需要能夠正確處理出現重復 message 的情況，

為什么不應該對所有的 message 都使用持久化機制？

首先，必然導致性能的下降，因為寫磁盤比寫 RAM 慢的多，message 的吞吐量可能有 10 倍的差距，

其次，message 的持久化機制用在 RabbitMQ 的內置 cluster 方案時會出現“坑爹”問題，矛盾點在于，若 message 設定了 persistent 屬性，但 queue 未設定durable 屬性，那么當該 queue 的 owner node 出現例外后，在未重建該 queue 前，發往該 queue 的 message 將被 blackholed ；若 message 設定了 persistent 屬性，同時queue 也設定了 durable 屬性，那么當 queue 的 owner node 例外且無法重啟的情況下，則該 queue 無法在其他 node 上重建，只能等待其 owner node 重啟后，才能恢復該 queue 的使用，而在這段時間內發送給該 queue 的 message 將被 blackholed ，所以，是否要對 message 進行持久化，需要綜合考慮性能需要，以及可能遇到的問題，若想達到 100,000 條/秒以上的訊息吞吐量（單 RabbitMQ 服務器），則要么使用其他的方式來確保 message 的可靠 delivery ，要么使用非常快速的存盤系統以支持全持久化（例如使

用 SSD），

另外一種處理原則是：僅對關鍵訊息作持久化處理（根據業務重要程度），且應該保證關鍵訊息的量不會導致性能瓶頸，

能夠在地理上分開的不同資料中心使用 RabbitMQ cluster 么？

不能，

第一，你無法控制所創建的 queue 實際分布在 cluster 里的哪個 node 上（一般使用

HAProxy + cluster 模型時都是這樣），這可能會導致各種跨地域訪問時的常見問題，

第二，Erlang 的 OTP 通信框架對延遲的容忍度有限，這可能會觸發各種超時，導致業務

疲于處理，

第三，在廣域網上的連接失效問題將導致經典的“腦裂”問題，而 RabbitMQ 目前無法

處理（該問題主要是說 Mnesia），

RabbitMQ 有那些基本概念？

• Broker：簡單來說就是訊息佇列服務器物體，
• Exchange：訊息交換機，它指定訊息按什么規則，路由到哪個佇列，
• Queue：訊息佇列載體，每個訊息都會被投入到一個或多個佇列，
• Binding：系結，它的作用就是把 exchange 和 queue 按照路由規則系結起來，
• Routing Key：路由關鍵字，exchange 根據這個關鍵字進行訊息投遞，
• VHost：vhost 可以理解為虛擬 broker ，即 mini-RabbitMQ server，其內部均含有獨立的 queue、exchange 和 binding 等，但最最重要的是，其擁有獨立的權限系統，可以做到 vhost 范圍的用戶控制，當然，從 RabbitMQ 的全域角度，vhost 可以作為不同權限隔離的手段（一個典型的例子就是不同的應用可以跑在不同的vhost 中），
• Producer：訊息生產者，就是投遞訊息的程式，
• Consumer：訊息消費者，就是接受訊息的程式，
• Channel：訊息通道，在客戶端的每個連接里，可建立多個 channel，每個 channel代表一個會話任務，由 Exchange、Queue、RoutingKey 三個才能決定一個從 Exchange 到 Queue 的唯
• 一的線路，

RocketMq會有重復消費的問題嗎？如何解決？

在網路中斷的情況下可能出現，需要保證消費端處理訊息的業務邏輯保持冪等性

RocketMq延遲訊息？如何實作的？

RocketMQ 支持定時訊息，但是不支持任意時間精度，僅支持特定的 level，例如定時 5s， 10s， 1m 等，其中，level=0 級表示不延時，level=1 表示 1 級延時，level=2 表示 2 級延時，默認的配置是messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h，

Message msg = new Message(topic, tags, keys, body);

msg.setDelayTimeLevel(3);

RocketMq是推模型還是拉模型？

rocketmq不管是推模式還是拉模式底層都是拉模式，推模式也是在拉模式上做了一層封裝.

訊息存盤在broker中，通過topic和tags區分訊息佇列，producer在發送訊息時不關心consumer對應的topic和tags，只將訊息發送到對應broker的對應topic和tags中，

推模式中broker則需要知道哪些consumer擁有哪些topic和tags，但在consumer重啟或更換topic時，broker無法及時獲取資訊，可能將訊息推送到舊的consumer中，對應consumer主動獲取topic，這樣確保每次主動獲取時他對應的topic資訊都是最新的，

RocketMQ訊息消費本質上是基于的拉（pull）模式，consumer主動向訊息服務器broker拉取訊息，

consumer被分為2類：MQPullConsumer和MQPushConsumer，其實本質都是拉模式（pull），即consumer輪詢從broker拉取訊息， 區別：

• MQPushConsumer方式，consumer把輪詢程序封裝了，并注冊MessageListener監聽器，取到訊息后，喚醒MessageListener的consumeMessage()來消費，對用戶而言，感覺訊息是被推送（push）過來的，主要用的也是這種方式，
• MQPullConsumer方式，取訊息的程序需要用戶自己寫，首先通過打算消費的Topic拿到MessageQueue的集合，遍歷MessageQueue集合，然后針對每個MessageQueue批量取訊息，一次取完后，記錄該佇列下一次要取的開始offset，直到取完了，再換另一個MessageQueue，

什么情況下會出現 blackholed 問題？

blackholed 問題是指，向 exchange 投遞了 message ，而由于各種原因導致該 message 丟失，但發送者卻不知道，可導致 blackholed 的情況：

1.向未系結 queue 的 exchange 發送 message；

2.exchange 以 binding_key key_A 系結了 queue queue_A，但向該 exchange 發送 message 使用的 routing_key 卻是 key_B，

如何防止出現 blackholed 問題？

沒有特別好的辦法，只能在具體實踐中通過各種方式保證相關 fabric 的存在，另外，如果在執行 Basic.Publish 時設定 mandatory=true ，則在遇到可能出現 blackholed 情況時，服務器會通過回傳 Basic.Return 告之當前 message 無法被正確投遞（內含原因 312NO_ROUTE），

Basic.Reject 的用法是什么？

該信令可用于 consumer 對收到的 message 進行 reject ，

若在該信令中設定requeue=true，則當 RabbitMQ server 收到該拒絕信令后，會將該 message 重新發送到下一個處于 consume 狀態的 consumer 處（理論上仍可能將該訊息發送給當前consumer），

若設定 requeue=false ，則 RabbitMQ server 在收到拒絕信令后，將直接將該 message 從 queue 中移除，

另外一種移除 queue 中 message 的小技巧是，consumer 回復 Basic.Ack 但不對獲取到的 message 做任何處理，而 Basic.Nack 是對 Basic.Reject 的擴展，以支持一次拒絕多條 message 的能力，

什么是 Binding 系結？

通過系結將交換器和佇列關聯起來，一般會指定一個 BindingKey,這樣 RabbitMq 就知道 如何正確路由訊息到佇列了，

RocketMq的負載均衡

生產者負載均衡

從MessageQueue串列中隨機選擇一個（默認策略），通過自增亂數對串列大小取余獲取位置資訊，但獲得的MessageQueue所在的集群不能是上次的失敗集群，

集群超時容忍策略，先隨機選擇一個MessageQueue，如果因為超時等例外發送失敗，會優先選擇該broker集群下其他的messeagequeue進行發送，如果沒有找到則從之前發送失敗broker集群中選擇一個MessageQueue進行發送，如果還沒有找到則使用默認策略，

消費者負載均衡

• 平均分配策略(默認)(AllocateMessageQueueAveragely)
• 環形分配策略(AllocateMessageQueueAveragelyByCircle)
• 手動配置分配策略(AllocateMessageQueueByConfig)
• 機房分配策略(AllocateMessageQueueByMachineRoom)
• 一致性哈希分配策略(AllocateMessageQueueConsistentHash)
• 靠近機房策略(AllocateMachineRoomNearby)

RocketMq訊息積壓

提高消費并行讀 同一個Consumer Group下，通過增加Consumer實體的數量來提高并行度，超過訂閱佇列數的Consumer實體無效，

提高單個Consumer的消費并行執行緒，通過修改Consumer的consumerThreadMin和consumerThreadMax來設定執行緒數

1. 批量方式消費 通過設定Consumer的consumerMessageBathMaxSize這個引數，默認是1，一次只消費一條訊息，例如設定N，那么每次消費的訊息條數小于等于N

2. 丟棄非重要訊息 當訊息發生堆積時，如果消費速度跟不上消費速度，可以選擇丟棄一些不重要的訊息

3. 優化訊息消費的程序 對于消費訊息的程序一般包括業務處理以及跟資料庫的互動，可以試著通過一些其他的方法優化消費的邏輯，

臨時解決方案：

新建一個topic，寫一個臨時的分發資料的consumer程式，這個程式部署上去消費積壓的資料，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的queue中，臨時用一部分機器來部署consumer，每一批consumer消費一個臨時queue的資料，等快速消費完積壓資料之后，得恢復原先部署架構，重新用原先的consumer機器來消費訊息

死信佇列和延遲佇列的使用

死信訊息：

1. 訊息被拒絕（Basic.Reject或Basic.Nack）并且設定 requeue 引數的值為 false
2. 訊息過期了
3. 佇列達到最大的長度

過期訊息：

在 rabbitmq 中存在2種方可設定訊息的過期時間，第一種通過對佇列進行設定，這種設定后，該佇列中所有的訊息都存在相同的過期時間，第二種通過對訊息本身進行設定，那么每條訊息的過期時間都不一樣，如果同時使用這2種方法，那么以過期時間小的那個數值為準，當訊息達到過期時間還沒有被消費，那么那個訊息就成為了一個 死信 訊息，

佇列設定：在佇列申明的時候使用 x-message-ttl 引數，單位為 毫秒

單個訊息設定：是設定訊息屬性的 expiration 引數的值，單位為 毫秒

延時佇列：在rabbitmq中不存在延時佇列，但是我們可以通過設定訊息的過期時間和死信佇列來模擬出延時佇列，消費者監聽死信交換器系結的佇列，而不要監聽訊息發送的佇列，