如何理解MQ死信隊列、重試隊列、消息回溯

本篇內(nèi)容主要講解“如何理解MQ死信隊列、重試隊列、消息回溯”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解MQ死信隊列、重試隊列、消息回溯”吧!

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

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

02.延遲隊列

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

03.死信隊列

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

04.重試隊列

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

05.消費模式之推模式push

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

06.消費模式之拉模式pull

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

07.消息回溯

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

08.消息堆積

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

09.消息追蹤/軌跡

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

10.消息過濾

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

11.消息審計

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

12.消息路由

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

到此，相信大家對“如何理解MQ死信隊列、重試隊列、消息回溯”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！