本文轉載自微信公衆號「搬運工來架構」，作者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