介紹

rabbitmq性能(1.2w+)高于activemq(6000+)，低于rocketmq（10w+）,通訊協議默認為amqp，通過插件擴展可支持stomp/mqtt等協議。

概念

連接

tcp連接

信道

tcp上封裝的虛擬連接，每個線程對應一個信道，即多路復用

生產者

消費者

消息

包括標簽（消息頭）和有效載荷（消息體）

交換器exchange

交換器直接與生產者交互，解耦生產者與隊列，隊列通過路由鍵綁定到交換器，本質為路由查詢表

交換器類型

• direct:1對1映射完全匹配交換器和隊列，默認交換器類型，默認以隊列名稱作為路由鍵
• fanout:廣播模式，忽略路由鍵配置，生產者發送的消息將由交換器發到所有與該交換器綁定的隊列（綁定了其他交換器的隊列并不會收到消息）
• topic:通配符模式，根據路由鍵中的通配符決定將消息發到符合條件的queue,通配符*表示匹配一個字符，#表示匹配一個或多個字符，.表示匹配分割符，如test.#，可以匹配test.開頭的所有路由鍵
• headers:通過報文頭中的自定義的鍵值對來確定消息存到哪個queue，實操中因為功能與direct雷同且性能較差，幾乎不用

隊列queue

消息存儲位置，直接與消費者交互，一個隊列可以有多個消費者

路由鍵

即交換器與隊列的映射，隊列可綁定多個路由鍵

虛擬主機vhost

可以隔離mq所有資源，有自己的權限，類比于命名空間

生產消費機制

生產消息

生產消息可以選擇模式，如下

• 無模式：即生產者將消息發給mq后就算結束，不關心消息是否已經落到queue中。
• 失敗確認：開啟故障檢測模式，設置mandatory,特點是只有當消息沒有落到queue中時會反饋給生產者，包括隊列不存在/路由沒有找到等情況。但是此種模式對于數據完整性來說有缺陷，無法保證反饋通知一定能通知到生產者（如此時生產者掛了），也就可能產生消息丟失的情況。
• 事務：性能太差
• 發送方確認模式：將信道設置為confirm模式，同事務模式沖突，可以與失敗確認組合使用，其中又可以分為三種
  • 同步確認：即發送完后同步等待消息確認
  • 批量確認：發送批量消息后同步等待確認，僅會對整批消息返回一條確認消息，失敗則意味著這批消息需要重發
  • 異步確認：即發送完后異步等待消息確認，通過先從信道中獲取消息發送序號存儲，等待消息落到queue中后，mq會通知生產者，此時可以將存儲的序號刪除，表示成功。

備用交換器

當主交換器無法路由到對應的queue時，將通過備用交換器進行路由，如設置了失敗確認模式，會在備用交換器也失敗的情況下才通知。

消息過期

主要有2種，

• queue設置過期時間，x-message-ttl 參數，RabbitMQ保證死消息（在隊列中的時間超過設定的TTL時間）不會被消費者獲得，同時會盡快刪除死的消費者。消息不會在消費者的緩沖區中過期，也就是說，只要隊列在消息過期前將消息推送給消費者，消費者就一定能處理到這條消息。重新入隊（例如被取消確認或者信道關閉或拒絕并重新入隊）的消息的過期時間保留初始值，即不刷新過期時間。
• 單條記錄設置過期時間，只對處于隊頭的消息判斷是否過期（即不會掃描隊列），所以，很可能隊列中已存在死消息，但是隊列并不知情。這會影響隊列統計數據的正確性，妨礙隊列及時釋放資源。

消費消息

拉取get

即為輪詢模式，當沒有消息時返回空回復

推送consume

常見使用方式，即mq有消息時主動推送給消費者

消息應答模式

與生產者的確認模式類似，消費者需要告訴mq消息是否已正確消費，目的是確保消息的完整性。主要有有種模式

• 自動確認：autoAck=true，即收到消息就自動確認
• 手動確認：mq會等待消費者返回ack信號后才刪除消息，在未收到ack時，消息處于正在消費階段，其他消費者無法消費到，只有當此消費者與mq斷開連接后（如果連接沒斷，mq允許消費者一直處理該條消息），mq認為此消息沒有被消費，將重新投遞給消費者。對于某些無法處理的消息，可以在消費者進行拒絕處理，此時該消息可以進入死信隊列，等待后續處理。

消息拒絕

消息拒絕有兩種方式，

• reject:可以使用requeue標識，=false則不重新發送（可進入死信隊列），=true則mq會重新投遞消息
• Nack:同reject,可以一次拒絕多個消息

死信交換器

概念同普通交換器沒有區別，只不過特意標識為用來處理‘死了的’消息，設置參數為x-dead-letter-exchange。使用場景主要為2種，對異常消息進行后續處理（如人工介入等），可以實現延時處理消息的能力（如實現下單待付款到時間關閉）
和備用交換器的區別

• 備用交換器是主交換器無法路由消息，那么消息將被路由到這個新的備用交換器，而死信交換器則是接收過期或者被拒絕的消息。
• 備用交換器是在聲明主交換器時發生聯系，而死信交換器則聲明隊列時發生聯系。
  場景分析:備用交換器一般是用于生產者生產消息時，確保消息可以盡量進入 RabbitMQ,而死信交換器主要是用于消費者消費消息的萬不一失性的場 景(比如消息過期，隊列滿了，消息拒絕且不重新投遞)

觸發時機

• 消 息被拒絕且requeue=false
• 消息過期（默認queue是不會過期,可以設置隊列過期或單條消息過期）
• 隊列達到最大值（默認無限長度）

隊列高可用

隊列屬性配置

參考

https://www.liangzl.com/get-article-detail-6832.html
https://blog.csdn.net/weixin_39776991/article/details/111618735