[[335625]]

本文轉(zhuǎn)載自微信公眾號「搬運(yùn)工來架構(gòu)」，作者cocodroid 。轉(zhuǎn)載本文請聯(lián)系搬運(yùn)工來架構(gòu)公眾號。

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

01.優(yōu)先級隊列

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

02.延遲隊列

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

03.死信隊列

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

04.重試隊列

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

05.消費(fèi)模式之推模式push

對于kafka而言，由Broker主動推送消息至消費(fèi)端，實(shí)時性較好，不過需要一定的流制機(jī)制來確保服務(wù)端推送過來的消息不會壓垮消費(fèi)端。

06.消費(fèi)模式之拉模式pull

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

07.消息回溯

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

08.消息堆積

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

09.消息追蹤/軌跡

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

10.消息過濾

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

11.消息審計

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

12.消息路由

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

參考資料

《深入理解Kafka》

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