[[335625]]

本文轉載自微信公眾號「搬運工來架構」，作者cocodroid 。轉載本文請聯系搬運工來架構公眾號。

消息隊列(MQ)的基本概念，很多時候都要了解清楚，這樣在學消息隊列中間件就比較能夠游刃有余，遇到不清楚的也可以重新翻來看看，加深理解。這里有關于：優先級隊列、延遲隊列、死信隊列、重試隊列、消息回溯、消息堆積、消息追蹤/消息軌跡、消息過濾、消息審計、消息路由等的介紹。

01.優先級隊列

優先級隊列不同于先進先出隊列，優先級高的消息具備優先被消費的特權，這樣可以為下游提供不同消息級別的保證。不過這個優先級也是需要有一個前提的：如果消費者的消費速度大于生產者的速度，并且消息中間件服務器(一般簡單的稱之為Broker)中沒有消息堆積，那么對于發送的消息設置優先級也就沒有什么實質性的意義了，因為生產者剛發送完一條消息就被消費者消費了，那么就相當于Broker中至多只有一條消息，對于單條消息來說優先級是沒有什么意義的。

02.延遲隊列

當你在網上購物的時候是否會遇到這樣的提示：“三十分鐘之內未付款，訂單自動取消”?這個是延遲隊列的一種典型應用場景。延遲隊列存儲的是對應的延遲消息，所謂“延遲消息”是指當消息被發送以后，并不想讓消費者立刻拿到消息，而是等待特定時間后，消費者才能拿到這個消息進行消費。延遲隊列一般分為兩種：基于消息的延遲和基于隊列的延遲。基于消息的延遲是指為每條消息設置不同的延遲時間，那么每當隊列中有新消息進入的時候就會重新根據延遲時間排序，當然這也會對性能造成極大的影響。實際應用中大多采用基于隊列的延遲，設置不同延遲級別的隊列，比如5s、10s、30s、1min、5mins、10mins等，每個隊列中消息的延遲時間都是相同的，這樣免去了延遲排序所要承受的性能之苦，通過一定的掃描策略(比如定時)即可投遞超時的消息。

03.死信隊列

由于某些原因消息無法被正確的投遞，為了確保消息不會被無故的丟棄，一般將其置于一個特殊角色的隊列，這個隊列一般稱之為死信隊列。與此對應的還有一個“回退隊列”的概念，試想如果消費者在消費時發生了異常，那么就不會對這一次消費進行確認(Ack),進而發生回滾消息的操作之后消息始終會放在隊列的頂部，然后不斷被處理和回滾，導致隊列陷入死循環。為了解決這個問題，可以為每個隊列設置一個回退隊列，它和死信隊列都是為異常的處理提供的一種機制保障。實際情況下，回退隊列的角色可以由死信隊列和重試隊列來扮演。

04.重試隊列

重試隊列其實可以看成是一種回退隊列，具體指消費端消費消息失敗時，為防止消息無故丟失而重新將消息回滾到Broker中。與回退隊列不同的是重試隊列一般分成多個重試等級，每個重試等級一般也會設置重新投遞延時，重試次數越多投遞延時就越大。舉個例子：消息第一次消費失敗入重試隊列Q1，Q1的重新投遞延遲為5s，在5s過后重新投遞該消息;如果消息再次消費失敗則入重試隊列Q2，Q2的重新投遞延遲為10s，在10s過后再次投遞該消息。以此類推，重試越多次重新投遞的時間就越久，為此需要設置一個上限，超過投遞次數就入死信隊列。重試隊列與延遲隊列有相同的地方，都是需要設置延遲級別，它們彼此的區別是：延遲隊列動作由內部觸發，重試隊列動作由外部消費端觸發;延遲隊列作用一次，而重試隊列的作用范圍會向后傳遞。

05.消費模式之推模式push

對于kafka而言，由Broker主動推送消息至消費端，實時性較好，不過需要一定的流制機制來確保服務端推送過來的消息不會壓垮消費端。

06.消費模式之拉模式pull

對于kafka而言，消費端主動向Broker端請求拉取(一般是定時或者定量)消息，實時性較推模式差，但是可以根據自身的處理能力而控制拉取的消息量。

07.消息回溯

一般消息在消費完成之后就被處理了，之后再也不能消費到該條消息。消息回溯正好相反，是指消息在消費完成之后，還能消費到之前被消費掉的消息。對于消息而言，經常面臨的問題是“消息丟失”，至于是真正由于消息中間件的缺陷丟失還是由于使用方的誤用而丟失一般很難追查，如果消息中間件本身具備消息回溯功能的話，可以通過回溯消費復現“丟失的”消息進而查出問題的源頭之所在。消息回溯的作用遠不止與此，比如還有索引恢復、本地緩存重建，有些業務補償方案也可以采用回溯的方式來實現。

08.消息堆積

流量削峰是消息中間件的一個非常重要的功能，而這個功能其實得益于其消息堆積能力。從某種意義上來講，如果一個消息中間件不具備消息堆積的能力，那么就不能把它看做是一個合格的消息中間件。消息堆積分內存式堆積和磁盤式堆積。

09.消息追蹤/軌跡

對于分布式架構系統中的鏈路追蹤(trace)而言，大家一定不會陌生。對于消息中間件而言，消息的鏈路追蹤(以下簡稱消息追蹤)同樣重要。對于消息追蹤最通俗的理解就是要知道消息從哪來，存在哪里以及發往哪里去。基于此功能下，我們可以對發送或者消費完的消息進行鏈路追蹤服務，進而可以進行問題的快速定位與排查。想要知道消息發送成功了嗎?發送的消息在消費端為什么消費不到?為什么又會重復消費?等等問題。引入消息軌跡可以知道消息從生產者觸發，經由broker等代理存儲，再到消費者消費的整個過程，各個節點的狀態、時間、地點等數據匯聚而成完整的鏈路信息。

10.消息過濾

消息過濾是指按照既定的過濾規則為下游用戶提供指定類別的消息。就以kafka而言，完全可以將不同類別的消息發送至不同的topic中，由此可以實現某種意義的消息過濾，或者Kafka還可以根據分區對同一個topic中的消息進行分類。不過更加嚴格意義上的消息過濾應該是對既定的消息采取一定的方式按照一定的過濾規則進行過濾。同樣以Kafka為例，可以通過客戶端提供的ConsumerInterceptor接口或者Kafka Stream的filter功能進行消息過濾。對于rocketmq來說，支持Tag、SQL92和類過濾器(新版去除)等3種模式。

11.消息審計

消息審計是指在消息在生產、存儲和消費的整個過程之間對消息個數及延遲的審計，以此來檢測是否有數據丟失、是否有數據重復、端到端的延遲又是多少等。有關產品：Uber的Chaperone、LinkedIn的kafka monitor、Confluent Control Center等，有需要或感興趣可自行通過網絡了解下。

12.消息路由

將消息路由到指定的隊列中，消費者消費隊列里的消息。RabbitMQ可以從交換器Exchanger根據路由鍵路由到指定一個或多個隊列。kafka默認是按照消息主題進行路由，消息路由在kafka中使用場景較少，使用起來也比較麻煩，如無特殊需要，一般不推薦使用。

參考資料

《深入理解Kafka》

http://www.likecs.com/default/index/show?id=14248