建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「搬運(yùn)工來(lái)架構(gòu)」，作者cocodroid 。轉(zhuǎn)載本文請(qǐng)聯(lián)系搬運(yùn)工來(lái)架構(gòu)公眾號(hào)。
創(chuàng)新互聯(lián)成立于2013年，先為長(zhǎng)子等服務(wù)建站，長(zhǎng)子等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為長(zhǎng)子企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
消息隊(duì)列(MQ)的基本概念，很多時(shí)候都要了解清楚，這樣在學(xué)消息隊(duì)列中間件就比較能夠游刃有余，遇到不清楚的也可以重新翻來(lái)看看，加深理解。這里有關(guān)于：優(yōu)先級(jí)隊(duì)列、延遲隊(duì)列、死信隊(duì)列、重試隊(duì)列、消息回溯、消息堆積、消息追蹤/消息軌跡、消息過(guò)濾、消息審計(jì)、消息路由等的介紹。
01.優(yōu)先級(jí)隊(duì)列
優(yōu)先級(jí)隊(duì)列不同于先進(jìn)先出隊(duì)列，優(yōu)先級(jí)高的消息具備優(yōu)先被消費(fèi)的特權(quán)，這樣可以為下游提供不同消息級(jí)別的保證。不過(guò)這個(gè)優(yōu)先級(jí)也是需要有一個(gè)前提的：如果消費(fèi)者的消費(fèi)速度大于生產(chǎn)者的速度，并且消息中間件服務(wù)器(一般簡(jiǎn)單的稱之為Broker)中沒(méi)有消息堆積，那么對(duì)于發(fā)送的消息設(shè)置優(yōu)先級(jí)也就沒(méi)有什么實(shí)質(zhì)性的意義了，因?yàn)樯a(chǎn)者剛發(fā)送完一條消息就被消費(fèi)者消費(fèi)了，那么就相當(dāng)于Broker中至多只有一條消息，對(duì)于單條消息來(lái)說(shuō)優(yōu)先級(jí)是沒(méi)有什么意義的。
02.延遲隊(duì)列
當(dāng)你在網(wǎng)上購(gòu)物的時(shí)候是否會(huì)遇到這樣的提示：“三十分鐘之內(nèi)未付款，訂單自動(dòng)取消”?這個(gè)是延遲隊(duì)列的一種典型應(yīng)用場(chǎng)景。延遲隊(duì)列存儲(chǔ)的是對(duì)應(yīng)的延遲消息，所謂“延遲消息”是指當(dāng)消息被發(fā)送以后，并不想讓消費(fèi)者立刻拿到消息，而是等待特定時(shí)間后，消費(fèi)者才能拿到這個(gè)消息進(jìn)行消費(fèi)。延遲隊(duì)列一般分為兩種：基于消息的延遲和基于隊(duì)列的延遲。基于消息的延遲是指為每條消息設(shè)置不同的延遲時(shí)間，那么每當(dāng)隊(duì)列中有新消息進(jìn)入的時(shí)候就會(huì)重新根據(jù)延遲時(shí)間排序，當(dāng)然這也會(huì)對(duì)性能造成極大的影響。實(shí)際應(yīng)用中大多采用基于隊(duì)列的延遲，設(shè)置不同延遲級(jí)別的隊(duì)列，比如5s、10s、30s、1min、5mins、10mins等，每個(gè)隊(duì)列中消息的延遲時(shí)間都是相同的，這樣免去了延遲排序所要承受的性能之苦，通過(guò)一定的掃描策略(比如定時(shí))即可投遞超時(shí)的消息。
03.死信隊(duì)列
由于某些原因消息無(wú)法被正確的投遞，為了確保消息不會(huì)被無(wú)故的丟棄，一般將其置于一個(gè)特殊角色的隊(duì)列，這個(gè)隊(duì)列一般稱之為死信隊(duì)列。與此對(duì)應(yīng)的還有一個(gè)“回退隊(duì)列”的概念，試想如果消費(fèi)者在消費(fèi)時(shí)發(fā)生了異常，那么就不會(huì)對(duì)這一次消費(fèi)進(jìn)行確認(rèn)(Ack),進(jìn)而發(fā)生回滾消息的操作之后消息始終會(huì)放在隊(duì)列的頂部，然后不斷被處理和回滾，導(dǎo)致隊(duì)列陷入死循環(huán)。為了解決這個(gè)問(wèn)題，可以為每個(gè)隊(duì)列設(shè)置一個(gè)回退隊(duì)列，它和死信隊(duì)列都是為異常的處理提供的一種機(jī)制保障。實(shí)際情況下，回退隊(duì)列的角色可以由死信隊(duì)列和重試隊(duì)列來(lái)扮演。
04.重試隊(duì)列
重試隊(duì)列其實(shí)可以看成是一種回退隊(duì)列，具體指消費(fèi)端消費(fèi)消息失敗時(shí)，為防止消息無(wú)故丟失而重新將消息回滾到Broker中。與回退隊(duì)列不同的是重試隊(duì)列一般分成多個(gè)重試等級(jí)，每個(gè)重試等級(jí)一般也會(huì)設(shè)置重新投遞延時(shí)，重試次數(shù)越多投遞延時(shí)就越大。舉個(gè)例子：消息第一次消費(fèi)失敗入重試隊(duì)列Q1，Q1的重新投遞延遲為5s，在5s過(guò)后重新投遞該消息;如果消息再次消費(fèi)失敗則入重試隊(duì)列Q2，Q2的重新投遞延遲為10s，在10s過(guò)后再次投遞該消息。以此類推，重試越多次重新投遞的時(shí)間就越久，為此需要設(shè)置一個(gè)上限，超過(guò)投遞次數(shù)就入死信隊(duì)列。重試隊(duì)列與延遲隊(duì)列有相同的地方，都是需要設(shè)置延遲級(jí)別，它們彼此的區(qū)別是：延遲隊(duì)列動(dòng)作由內(nèi)部觸發(fā)，重試隊(duì)列動(dòng)作由外部消費(fèi)端觸發(fā);延遲隊(duì)列作用一次，而重試隊(duì)列的作用范圍會(huì)向后傳遞。
05.消費(fèi)模式之推模式push
對(duì)于kafka而言，由Broker主動(dòng)推送消息至消費(fèi)端，實(shí)時(shí)性較好，不過(guò)需要一定的流制機(jī)制來(lái)確保服務(wù)端推送過(guò)來(lái)的消息不會(huì)壓垮消費(fèi)端。
06.消費(fèi)模式之拉模式pull
對(duì)于kafka而言，消費(fèi)端主動(dòng)向Broker端請(qǐng)求拉取(一般是定時(shí)或者定量)消息，實(shí)時(shí)性較推模式差，但是可以根據(jù)自身的處理能力而控制拉取的消息量。
07.消息回溯
一般消息在消費(fèi)完成之后就被處理了，之后再也不能消費(fèi)到該條消息。消息回溯正好相反，是指消息在消費(fèi)完成之后，還能消費(fèi)到之前被消費(fèi)掉的消息。對(duì)于消息而言，經(jīng)常面臨的問(wèn)題是“消息丟失”，至于是真正由于消息中間件的缺陷丟失還是由于使用方的誤用而丟失一般很難追查，如果消息中間件本身具備消息回溯功能的話，可以通過(guò)回溯消費(fèi)復(fù)現(xiàn)“丟失的”消息進(jìn)而查出問(wèn)題的源頭之所在。消息回溯的作用遠(yuǎn)不止與此，比如還有索引恢復(fù)、本地緩存重建，有些業(yè)務(wù)補(bǔ)償方案也可以采用回溯的方式來(lái)實(shí)現(xiàn)。
08.消息堆積
流量削峰是消息中間件的一個(gè)非常重要的功能，而這個(gè)功能其實(shí)得益于其消息堆積能力。從某種意義上來(lái)講，如果一個(gè)消息中間件不具備消息堆積的能力，那么就不能把它看做是一個(gè)合格的消息中間件。消息堆積分內(nèi)存式堆積和磁盤(pán)式堆積。
09.消息追蹤/軌跡
對(duì)于分布式架構(gòu)系統(tǒng)中的鏈路追蹤(trace)而言，大家一定不會(huì)陌生。對(duì)于消息中間件而言，消息的鏈路追蹤(以下簡(jiǎn)稱消息追蹤)同樣重要。對(duì)于消息追蹤最通俗的理解就是要知道消息從哪來(lái)，存在哪里以及發(fā)往哪里去。基于此功能下，我們可以對(duì)發(fā)送或者消費(fèi)完的消息進(jìn)行鏈路追蹤服務(wù)，進(jìn)而可以進(jìn)行問(wèn)題的快速定位與排查。想要知道消息發(fā)送成功了嗎?發(fā)送的消息在消費(fèi)端為什么消費(fèi)不到?為什么又會(huì)重復(fù)消費(fèi)?等等問(wèn)題。引入消息軌跡可以知道消息從生產(chǎn)者觸發(fā)，經(jīng)由broker等代理存儲(chǔ)，再到消費(fèi)者消費(fèi)的整個(gè)過(guò)程，各個(gè)節(jié)點(diǎn)的狀態(tài)、時(shí)間、地點(diǎn)等數(shù)據(jù)匯聚而成完整的鏈路信息。
10.消息過(guò)濾
消息過(guò)濾是指按照既定的過(guò)濾規(guī)則為下游用戶提供指定類別的消息。就以kafka而言，完全可以將不同類別的消息發(fā)送至不同的topic中，由此可以實(shí)現(xiàn)某種意義的消息過(guò)濾，或者Kafka還可以根據(jù)分區(qū)對(duì)同一個(gè)topic中的消息進(jìn)行分類。不過(guò)更加嚴(yán)格意義上的消息過(guò)濾應(yīng)該是對(duì)既定的消息采取一定的方式按照一定的過(guò)濾規(guī)則進(jìn)行過(guò)濾。同樣以Kafka為例，可以通過(guò)客戶端提供的ConsumerInterceptor接口或者Kafka Stream的filter功能進(jìn)行消息過(guò)濾。對(duì)于rocketmq來(lái)說(shuō)，支持Tag、SQL92和類過(guò)濾器(新版去除)等3種模式。
11.消息審計(jì)
消息審計(jì)是指在消息在生產(chǎn)、存儲(chǔ)和消費(fèi)的整個(gè)過(guò)程之間對(duì)消息個(gè)數(shù)及延遲的審計(jì)，以此來(lái)檢測(cè)是否有數(shù)據(jù)丟失、是否有數(shù)據(jù)重復(fù)、端到端的延遲又是多少等。有關(guān)產(chǎn)品：Uber的Chaperone、LinkedIn的kafka monitor、Confluent Control Center等，有需要或感興趣可自行通過(guò)網(wǎng)絡(luò)了解下。
12.消息路由
將消息路由到指定的隊(duì)列中，消費(fèi)者消費(fèi)隊(duì)列里的消息。RabbitMQ可以從交換器Exchanger根據(jù)路由鍵路由到指定一個(gè)或多個(gè)隊(duì)列。kafka默認(rèn)是按照消息主題進(jìn)行路由，消息路由在kafka中使用場(chǎng)景較少，使用起來(lái)也比較麻煩，如無(wú)特殊需要，一般不推薦使用。
參考資料
《深入理解Kafka》
http://www.likecs.com/default/index/show?id=14248
網(wǎng)站欄目：這些MQ概念你都懂嗎：死信隊(duì)列、重試隊(duì)列、消息回溯等
文章來(lái)源：http://m.fisionsoft.com.cn/article/dpccoho.html
