RabbitMQ消息中間件技術(shù)精講9 高級篇二

高并發(fā)場景下，消息的延遲投遞做二次確認(rèn)進(jìn)行回調(diào)檢查來保障生產(chǎn)者消息投遞成功的可靠性

在上一篇文章中，我們介紹了BAT大廠中一種方式保障生成者消息投遞可靠性。思考：在上一篇中可靠性投遞，在高并發(fā)的場景下是否合適？

其實(shí)在上一篇文章中，我們實(shí)際上對數(shù)據(jù)庫操作了兩次：業(yè)務(wù)數(shù)據(jù)入庫和消息信息入庫。這中對數(shù)據(jù)庫多次操作的，如果在高并發(fā)場景下會出現(xiàn)問題的。所以我們可以使用二種情況：消息的延遲投遞，做二次確認(rèn)，回調(diào)檢查。

本文主要內(nèi)容：

消息的延遲投遞做二次確認(rèn)，回調(diào)檢查。

延遲投遞流程圖：

流程說明：

Upstream Service:上游服務(wù)

DownStream Service:下游服務(wù)

Callback service:回調(diào)服務(wù)

執(zhí)行流程：

Step1：

????業(yè)務(wù)信息入庫(BIZ DB)之后，向MQ發(fā)送一個(gè)消息：first Send。這個(gè)消息時(shí)通知下游服務(wù)進(jìn)行下游業(yè)務(wù)處理的；

Setp2:

????First Send消息發(fā)送后，同時(shí)發(fā)送一個(gè)Second Send Delay Check消息。這個(gè)消息是用來延時(shí)check驗(yàn)證的。如延遲5分鐘(具體延遲多少時(shí)間，根據(jù)實(shí)際業(yè)務(wù))；

Setp3:

????下游服務(wù)有一個(gè)用于接收上有服務(wù)發(fā)送消息的消費(fèi)者:Listener Consume。當(dāng)消費(fèi)者接收到生產(chǎn)者發(fā)送的消息后進(jìn)行業(yè)務(wù)處理。處理完成后，執(zhí)行第四步操作；

Setp4:

????當(dāng)消費(fèi)者消費(fèi)后，自己業(yè)務(wù)處理完成之后，會發(fā)送一個(gè)確認(rèn)的消息(Send Confirm)給隊(duì)列。

Step5:

????下游服務(wù)生產(chǎn)一個(gè)確認(rèn)消息后，在回調(diào)服務(wù)(Callback Serivce)中會有一個(gè)消費(fèi)者(Listener Confirm)消費(fèi)這個(gè)確認(rèn)消息后，將消息信息入庫或更新消息狀態(tài)。

五分鐘后，延遲校驗(yàn)消息開始生效，進(jìn)行校驗(yàn)，進(jìn)行第六步

Setp6:

????當(dāng)延遲校驗(yàn)在Callback Service服務(wù)中進(jìn)行查詢消息庫，發(fā)現(xiàn)沒有或者是狀態(tài)沒有進(jìn)行預(yù)期的更新后，延遲校驗(yàn)會會通過主鍵或者其他唯一標(biāo)識通過RPC方式發(fā)起一個(gè)RPC ReSend Command請求到上游服務(wù)，詢問此條消息下游未正常處理。請求上游服務(wù)再次發(fā)送消息操作。

此種操作相對于第一種操作的優(yōu)點(diǎn)：減少了一次同步操作數(shù)據(jù)庫的操作。這樣在高并發(fā)的情況下就能提高效率。

好了，兩種保障生產(chǎn)者投遞消息可靠性已經(jīng)講完了。在下節(jié)課中，我們將講解下一個(gè)知識點(diǎn)：冪等性。下節(jié)預(yù)告：

1：冪等性是什么

2：在海量訂單產(chǎn)生的業(yè)務(wù)高峰期，如何避免消息的重復(fù)消費(fèi)問題？

3：業(yè)界主流的冪等性操作都有哪些？

歡迎關(guān)注凱哥公眾號：凱哥Java(kaigejava)

凱哥個(gè)人博客：www.kaigejava.com