[發(fā)明專(zhuān)利]用于消息隊(duì)列的消息丟失檢測(cè)方法和裝置

在審

• 申請(qǐng)?zhí)枺?/td>: 201911330718.6
• 申請(qǐng)日: 2019-12-20
• 公開(kāi)（公告）號(hào): CN111190747A
• 公開(kāi)（公告）日: 2020-05-22
• 發(fā)明（設(shè)計(jì)）人: 馬鵬程;胡偉
• 申請(qǐng)（專(zhuān)利權(quán)）人: 北京金山云網(wǎng)絡(luò)技術(shù)有限公司
• 主分類(lèi)號(hào): G06F9/54
• 分類(lèi)號(hào): G06F9/54
• 代理公司: 北京華夏泰和知識(shí)產(chǎn)權(quán)代理有限公司 11662
• 代理人: 韓來(lái)兵;李雪

本申請(qǐng)公開(kāi)了一種用于消息隊(duì)列的消息丟失檢測(cè)方法和裝置。其中，該方法包括：接收生產(chǎn)者發(fā)送的業(yè)務(wù)消息和業(yè)務(wù)消息的消息標(biāo)識(shí)，業(yè)務(wù)消息用于表示待消費(fèi)者執(zhí)行的目標(biāo)任務(wù)；將業(yè)務(wù)消息存儲(chǔ)至消息隊(duì)列和將消息標(biāo)識(shí)存儲(chǔ)至數(shù)據(jù)庫(kù)，消息隊(duì)列和數(shù)據(jù)庫(kù)與消費(fèi)者之間獨(dú)立通信；通過(guò)消息隊(duì)列將業(yè)務(wù)消息發(fā)送給消費(fèi)者，以使消費(fèi)者執(zhí)行目標(biāo)任務(wù)并存儲(chǔ)業(yè)務(wù)消息的消息標(biāo)識(shí)；在數(shù)據(jù)庫(kù)接收到消費(fèi)者的查詢(xún)請(qǐng)求時(shí)，通過(guò)數(shù)據(jù)庫(kù)將消息標(biāo)識(shí)發(fā)送給消費(fèi)者，以使消費(fèi)者根據(jù)數(shù)據(jù)庫(kù)存儲(chǔ)的消息標(biāo)識(shí)和消費(fèi)者存儲(chǔ)的消息標(biāo)識(shí)確定是否存在丟失的業(yè)務(wù)消息。本申請(qǐng)解決了相關(guān)技術(shù)中不能準(zhǔn)確檢測(cè)丟失的消息的技術(shù)問(wèn)題。

技術(shù)領(lǐng)域

本申請(qǐng)涉及互聯(lián)網(wǎng)領(lǐng)域，具體而言，涉及一種用于消息隊(duì)列的消息丟失檢測(cè)方法和裝置。

背景技術(shù)

遠(yuǎn)程過(guò)程調(diào)用RPC(Remote Procedure Call)，通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議，RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層，RPC使得開(kāi)發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

在分布式系統(tǒng)架構(gòu)中，RPC是一項(xiàng)通用技術(shù)，用來(lái)實(shí)現(xiàn)消息可靠有序的傳遞，該技術(shù)是分布式系統(tǒng)環(huán)境中確保系統(tǒng)穩(wěn)定運(yùn)行的關(guān)鍵因素之一，以openstack-neutron組件(一種用于網(wǎng)絡(luò)虛擬化的組件)為例，其系統(tǒng)架構(gòu)如圖1所示。在如圖1所示的系統(tǒng)架構(gòu)中，如果用戶(hù)給neutron-server(生產(chǎn)者)發(fā)送HTTP請(qǐng)求，該請(qǐng)求用來(lái)請(qǐng)求創(chuàng)建兩個(gè)網(wǎng)段之間的路由條目，實(shí)現(xiàn)兩個(gè)網(wǎng)段之間的IP三層可達(dá)，若生產(chǎn)者沒(méi)有將請(qǐng)求準(zhǔn)確的發(fā)送給L3代理(或稱(chēng)L3-agent，即接收采用FANOUT方式發(fā)送的業(yè)務(wù)消息的消費(fèi)者的代理)，則L3代理就無(wú)法給對(duì)應(yīng)的網(wǎng)關(guān)配置路由項(xiàng)，本次HTTP請(qǐng)求的功能就不能實(shí)現(xiàn)。

在生產(chǎn)者將請(qǐng)求發(fā)送給L3代理的過(guò)程中，生產(chǎn)者通過(guò)消息隊(duì)列MQ(全稱(chēng)是MessageQueue)發(fā)送消息給消費(fèi)者xxx-agent(其中“xxx”為具體消費(fèi)者的標(biāo)識(shí)，如L3和OVS)，可能會(huì)出現(xiàn)以下幾種異常情況導(dǎo)致生產(chǎn)者沒(méi)有將請(qǐng)求準(zhǔn)確的發(fā)送給消費(fèi)者：

(1)生產(chǎn)者在發(fā)送消息給消息隊(duì)列的時(shí)候出現(xiàn)異常，比如TCP連接中斷，導(dǎo)致消息沒(méi)有發(fā)送到消息隊(duì)列中，該異常生產(chǎn)者應(yīng)該是可以捕獲到；

(2)消息隊(duì)列突然宕機(jī)，保存到消息隊(duì)列的隊(duì)列Queue中的消息沒(méi)有持久化，重啟以后消息丟失；

(3)消費(fèi)者與消息隊(duì)列之間的連接斷開(kāi)，但是生產(chǎn)者還給這個(gè)消費(fèi)者發(fā)送消息，導(dǎo)致消息隊(duì)列中對(duì)應(yīng)的隊(duì)列出現(xiàn)消息堆積，且不能發(fā)送給生產(chǎn)者。

在發(fā)生可能導(dǎo)致消息丟失的以上幾種異常情況時(shí)，業(yè)界普遍采用以下解決方案：

方案一，消息持久化：主要包括對(duì)Exchange設(shè)置持久化，Queue設(shè)置持久化，消息Message持久化發(fā)送，在發(fā)送消息設(shè)置中設(shè)置發(fā)送模式deliveryMode＝2，在默認(rèn)情況下，如果消息隊(duì)列集群宕機(jī)重啟，會(huì)導(dǎo)致所有的Exchange和Queue以及沒(méi)有被消費(fèi)的業(yè)務(wù)消息全部丟失，通過(guò)Exchange持久化，Queue持久化以及業(yè)務(wù)消息持久化，在消息隊(duì)列宕機(jī)重啟以后，能夠快速的恢復(fù)到宕機(jī)前的狀態(tài)。

方案二，ack確認(rèn)機(jī)制：目前的消息發(fā)送確認(rèn)中，ConfirmCallback只確認(rèn)消息是否正確到達(dá)Exchange中；ReturnCallback在消息沒(méi)有正確到達(dá)隊(duì)列時(shí)觸發(fā)回調(diào)，如果正確到達(dá)隊(duì)列則不執(zhí)行。在消息接收確認(rèn)時(shí)，默認(rèn)情況下消息消費(fèi)者是自動(dòng)發(fā)送ack確認(rèn)消息的，該方案采用自動(dòng)確認(rèn)，會(huì)在消息發(fā)送給消費(fèi)者代理后立即確認(rèn)，這樣存在丟失消息的可能，如消費(fèi)者代理未保存成功、未成功發(fā)送給消費(fèi)者等。