消息無序產(chǎn)生的原因

消息隊列，既然是隊列就能保證消息在進入隊列，以及出隊列的時候保證消息的有序性，顯然這是在消息的生產(chǎn)端(Producer)，但是往往在生產(chǎn)環(huán)境中有多個消息的消費端(Consumer)，盡管消費端在拉取消息時是有序的，但各個消息由于網(wǎng)絡等方面原因無法保證在各個消費端中處理時有序。

成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站設計、成都網(wǎng)站制作、外貿(mào)網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的南澳網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

場景分析

先后兩次修改了商品信息，消息A和消息B先后同步寫入MySQL，接著異步寫入消息隊列中發(fā)送消息，此時消息隊列生產(chǎn)端（Producer）按時序先后發(fā)出了A和B兩條消息(消息A先發(fā)出，消息B后發(fā)出)。按業(yè)務邏輯，商品信息的最終狀態(tài)需要以消息A和消息B綜合為準。

看似一個比較常見的同步寫數(shù)據(jù)庫，異步發(fā)送消息的場景，但實際上需要保證消息的有序消費。

• 假設1：消息A只包含修改的商品名稱，消息B只包含修改的商品重量，此時消息隊列的消費端實際上不需要關注消息時序，消息隊列消費端（Consumer）只管消費即可。
• 假設2：消息A包含修改的商品名稱、重量，消息B包含修改的商品名稱，此時消費端首先接收到消息B，后接收到消息A，那么消息B的修改就會被覆蓋。此時消息隊列的消費端實際上又需要關注消息時序。

可見，你無法保證消息中包含什么信息，此時必須保證消息的有序消費。

業(yè)務角度如何保證消息有序消費

• 生產(chǎn)端在發(fā)送消息時，始終保證消息是全量信息。
• 消費端在接收消息時，通過緩存時間戳的方式，消費消息時判斷消息產(chǎn)生的時間是否最新，如果不是則丟棄，如果是則執(zhí)行下一步。

下面通過偽代碼的方式描述：

生產(chǎn)端偽代碼

insertWare(ware); #插入數(shù)據(jù)到數(shù)據(jù)庫，通常在插入數(shù)據(jù)庫時我們只會update修改的字段，而不會全量插入

ware = selectWareById(ware.getId); #獲取商品的全量信息（此時是最新的），用于將它放入到消息隊列中

syncMq(ware); #異步發(fā)送mq消息A

消費端偽代碼

ware = fetchWare(); #獲取消息

if (isLasted(ware)) #通過商品的修改時間戳判斷是否是最新的修改

? TODO #執(zhí)行下一步業(yè)務邏輯

else

? return #丟棄該消息

重點在于消費端如何判斷該消息是否是最新的修改也就是isLasted方法。

isLasted方法

Long modified = getCacheById(ware.getId); #獲取緩存中該條商品的最新修改時間

If (ware.getModified > modified) { #如果消息中商品修改時間大于緩存中的時間，說明是最新操作

? setCacheById(ware); #將該條消息的商品修改時間戳寫入到緩存中

? return true;
} else #如果消息中的商品修改時間小于緩存中的時間，說明該條消息屬于“歷史操作”，不對其更新

? return false;

以上就是通過偽代碼的方式，描述如何通過業(yè)務手段保證消息有序消費，重點在于全量發(fā)送信息和緩存時間戳。在其中還有一些技術實現(xiàn)細節(jié)。

例如：消費端消費消息B，執(zhí)行到獲取時間戳緩存之后，并在重新設置新的緩存之前，此時另一個消費端恰好也正在消費B它也正執(zhí)行到獲取時間戳緩存，由于消息A此時并沒有更新緩存，消息A拿到的緩存仍然是舊的緩存，這時就會存在兩個消費端都認為自己所消費的消息時最新的，造成該丟棄的消息沒丟。

顯然，這是分布式線程安全問題，分布式鎖通常使用redis或者ZooKeeper，加鎖后的執(zhí)行時序如下圖所示。

這是從業(yè)務角度保證消息在消費端有序消費。通過在消息發(fā)送端全量發(fā)送消息以及在消息消費端緩存時間戳就可以保證消息的有序消費。

在上述場景中是先同步寫入MySQL，再獲取商品全量數(shù)據(jù)，接著再異步發(fā)送消息。這一系列的步驟可以通過接MySQL的binlog實現(xiàn)，在同步寫入MySQL后，MySQL發(fā)送binlog變更，通過阿里巴巴Canal中間件接收MySQL的binlog變更再發(fā)送消息到消息隊列。

名稱欄目：消費端如何保證消息隊列MQ的有序消費
標題路徑：http://jinyejixie.com/article4/pgesie.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設計、網(wǎng)站排名、做網(wǎng)站、標簽優(yōu)化、關鍵詞優(yōu)化、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)