張 杰,滿曙光,劉 凱,周立軍

1(海軍航空大學(xué) 航空基礎(chǔ)學(xué)院,煙臺(tái) 264001)

2(煙臺(tái)市公安局,煙臺(tái) 264001)

隨著企業(yè)級(jí)應(yīng)用的業(yè)務(wù)復(fù)雜度和規(guī)模的不斷擴(kuò)大,傳統(tǒng)的單體應(yīng)用系統(tǒng)在維護(hù)、部署、擴(kuò)展以及穩(wěn)定性、并發(fā)性等方面,普遍存在難以逾越瓶頸,這也導(dǎo)致各種相對(duì)獨(dú)立的傳統(tǒng)軟件系統(tǒng)在集成時(shí)面臨的困難,如系統(tǒng)堆砌、問(wèn)題定位難、擴(kuò)展性差、可靠性不高、維護(hù)成本高等[1],為適應(yīng)移動(dòng)互聯(lián)網(wǎng)高速發(fā)展以及在項(xiàng)目開(kāi)發(fā)敏捷、精益、持續(xù)交付等應(yīng)用需求背景,傳統(tǒng)的單體應(yīng)用系統(tǒng)面臨功能重復(fù)開(kāi)發(fā)、功能監(jiān)控與評(píng)估(性能)難以進(jìn)行,由于軟件構(gòu)件復(fù)用效率低,當(dāng)面對(duì)業(yè)務(wù)需求變更時(shí),使得應(yīng)用系統(tǒng)臃腫、維護(hù)困難,頻繁部署,甚至給軟件測(cè)試帶來(lái)更多不確定性,導(dǎo)致系統(tǒng)無(wú)法持續(xù)工作[2],此外高并發(fā)性是單體應(yīng)用難以逾越的鴻溝,為解決上述問(wèn)題,使用微服務(wù)(micro-service)實(shí)現(xiàn)組件化成為系統(tǒng)設(shè)計(jì)的新選擇,并得到飛速發(fā)展和應(yīng)用,微服務(wù)架構(gòu)通過(guò)將系統(tǒng)按服務(wù)組件化分解,服務(wù)之間通過(guò)Http 等通信協(xié)議進(jìn)行協(xié)作,并且各個(gè)服務(wù)都可單獨(dú)開(kāi)發(fā)、部署,最終通過(guò)服務(wù)之間組合與調(diào)用對(duì)外完成系統(tǒng)功能[3,4].

微服務(wù)在解決上述問(wèn)題同時(shí),也引入了諸多不確定因素,如執(zhí)行一項(xiàng)完整的業(yè)務(wù),需要調(diào)用多個(gè)微服務(wù)協(xié)同工作,當(dāng)依賴微服務(wù)調(diào)用出現(xiàn)故障(操作失敗),已經(jīng)完成的微服務(wù)如何處理[5,6],此時(shí)主要涉及微服務(wù)的可用性與數(shù)據(jù)一致性等問(wèn)題,針對(duì)上述問(wèn)題,本文首先闡述了單體系統(tǒng)中事務(wù)與分布式系統(tǒng)事務(wù)的基本原理,分析了微服務(wù)在數(shù)據(jù)一致性問(wèn)題上遵循的原則,提出了一種使用事務(wù)型消息隊(duì)列實(shí)現(xiàn)微服務(wù)數(shù)據(jù)最終一致性方法,通過(guò)典型應(yīng)用場(chǎng)景分析,給出使用RocketMQ消息隊(duì)列實(shí)現(xiàn)了分布式數(shù)據(jù)一致性方法,通過(guò)實(shí)驗(yàn)表明事務(wù)型消息在解決上述問(wèn)題時(shí)具有易于實(shí)現(xiàn)、可靠性高、并發(fā)處理能力強(qiáng)等特點(diǎn),最后總結(jié)RocketMQ事務(wù)型消息隊(duì)列實(shí)現(xiàn)難點(diǎn)及不足.

1 數(shù)據(jù)一致性基本原則

傳統(tǒng)的單體應(yīng)用系統(tǒng)中,通常使用一個(gè)關(guān)系型數(shù)據(jù)庫(kù),通過(guò)關(guān)系型數(shù)據(jù)庫(kù)事務(wù)保證數(shù)據(jù)的一致性,這種事務(wù)有四個(gè)基本要素(ACID)[7]：原子性、一致性、隔離性、持久性.為了應(yīng)對(duì)高并發(fā)的挑戰(zhàn),應(yīng)用系統(tǒng)需要多個(gè)數(shù)據(jù)庫(kù)來(lái)支持,可通過(guò)分布式事務(wù)來(lái)保證數(shù)據(jù)一致性,根據(jù)CAP 理論：分布式系統(tǒng)不可能同時(shí)滿足一致性、可用性和分區(qū)容錯(cuò)性這三個(gè)要求,最多只能同時(shí)滿足兩個(gè)[8].鑒于網(wǎng)絡(luò)硬件出現(xiàn)閃斷、延遲丟包等問(wèn)題不可避免,分區(qū)容忍性必須需要實(shí)現(xiàn),同時(shí)可用性體現(xiàn)了分布式應(yīng)用系統(tǒng)持續(xù)提供服務(wù)的能力,若滿足一致性則需付出在滿足一致性之前阻塞其他并發(fā)訪問(wèn)的代價(jià)[9],事實(shí)上可用性與分區(qū)容忍性優(yōu)先級(jí)要高于數(shù)據(jù)一致性,所以只能在數(shù)據(jù)一致性上做出取舍,分布式數(shù)據(jù)一致性級(jí)別又可分為：

強(qiáng)一致性：類似于單體事務(wù)數(shù)據(jù)一致性,但實(shí)現(xiàn)起來(lái)往往對(duì)系統(tǒng)的并發(fā)性能影響大.

弱一致性：約束了數(shù)據(jù)更新成功后,不承諾立即可以讀到寫入的數(shù)據(jù),也不久承諾多久之后數(shù)據(jù)能夠達(dá)到一致,但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別(比如秒級(jí)),數(shù)據(jù)能夠達(dá)到一致?tīng)顟B(tài).

最終一致性：作為弱一致性的一個(gè)特例,系統(tǒng)會(huì)保證在一定時(shí)間內(nèi),能夠達(dá)到數(shù)據(jù)一致的狀態(tài).

在微服務(wù)架構(gòu)中,數(shù)據(jù)訪問(wèn)與分布式架構(gòu)相比更加復(fù)雜,通常情況下,數(shù)據(jù)都是每個(gè)微服務(wù)私有,只能通過(guò)API 的方式訪問(wèn)數(shù)據(jù).這種方式可以實(shí)現(xiàn)微服務(wù)間的松耦合,使彼此獨(dú)立的微服務(wù)更容易的進(jìn)行擴(kuò)展.隨之帶來(lái)問(wèn)題是：數(shù)據(jù)不一致性既不能依靠底層數(shù)據(jù)庫(kù)事務(wù)實(shí)現(xiàn),也無(wú)法通過(guò)統(tǒng)一的事務(wù)協(xié)調(diào)器來(lái)完成數(shù)據(jù)一致性,傳統(tǒng)的本地事務(wù)或分布式事務(wù)不適合微服務(wù)架構(gòu).

微服務(wù)架構(gòu)作為分布式架構(gòu)的一種,數(shù)據(jù)一致性通常采用BASE 理論,BASE 理論是對(duì)CAP 理論的延伸,核心思想是即使無(wú)法做到強(qiáng)一致性[10],但應(yīng)用可以采用適合的方式達(dá)到最終一致性(Eventual Consitency),BASE 模型完全不同ACID 模型,該模型犧牲高一致性,獲得可用性和可靠性[11].

在微服務(wù)實(shí)現(xiàn)數(shù)據(jù)一致性時(shí),首先應(yīng)保證調(diào)用微服務(wù)具有冪等性,冪等性是指一個(gè)操作(特定服務(wù)一次調(diào)用)至多只會(huì)被處理一次,后續(xù)調(diào)用都將返回第一次調(diào)用時(shí)的處理結(jié)果[12].

2 事務(wù)型消息一致性處理方法

2.1 一致性應(yīng)用場(chǎng)景分析

在分布式架構(gòu)中,以學(xué)員選課應(yīng)用場(chǎng)景為例,基本業(yè)務(wù)邏輯如下：

(1)選課服務(wù)S1 負(fù)責(zé)學(xué)員執(zhí)行選課操作,完成選課信息保存；

(2)統(tǒng)計(jì)服務(wù)S2 負(fù)責(zé)統(tǒng)計(jì)選課信息,執(zhí)行匯總計(jì)算操作；

(3)通知服務(wù)S3 負(fù)責(zé)通知任課老師選課信息.

選課業(yè)務(wù)中體現(xiàn)的分布式數(shù)據(jù)一致性要求主要體現(xiàn)在：

(1) 選課服務(wù)S1 完成選課操作成功,統(tǒng)計(jì)服務(wù)S2 成功接收到學(xué)員選課信息,并進(jìn)行匯總操作；

(2) 選課服務(wù)S1 完成選課操作成功,通知服務(wù)S3 成功接收到學(xué)員選課信息；

在圖1展示的業(yè)務(wù)中,首先執(zhí)行本地?cái)?shù)據(jù)庫(kù)事務(wù)方法,其次發(fā)布消息,當(dāng)消息發(fā)布失敗會(huì)導(dǎo)致消息發(fā)布者本地事務(wù)回滾,現(xiàn)實(shí)中數(shù)據(jù)庫(kù)事務(wù)回滾的成本相對(duì)于消息發(fā)布失敗高很多,這明顯是不符合預(yù)期[13].

為了解決這個(gè)問(wèn)題,可以采用消息隊(duì)列作為中間件(如圖2),消息隊(duì)列普遍用于各微服務(wù)之間異步通訊[14],為實(shí)現(xiàn)以上數(shù)據(jù)一致性要求,采用事務(wù)型消息隊(duì)列實(shí)現(xiàn)微服務(wù)S1、S2和S3 之間的提供異步通信服務(wù),首先將選課服務(wù)S1 選課操作分解為3 個(gè)步驟完成,且封裝在一個(gè)本地事務(wù)中：

(1)將選課信息發(fā)布事務(wù)型消息到消息隊(duì)列；

(2)執(zhí)行保存選課信息操作；

(3)根據(jù)執(zhí)行步驟(2)執(zhí)行結(jié)果,決定是否將消息投遞給服務(wù)S2和S3.

圖2 改造后選課業(yè)務(wù)

消息隊(duì)列提供一種特殊類型的消息：事務(wù)型消息,這類消息的特點(diǎn)是：消息隊(duì)列收到消息后不會(huì)立刻投遞消息到消息訂閱者(服務(wù)S2和S3),而是根據(jù)消息發(fā)布者應(yīng)用的數(shù)據(jù)庫(kù)事務(wù)狀態(tài)決定消息是否投遞.如果選課服務(wù)S1 數(shù)據(jù)庫(kù)事務(wù)提交,則消息投遞到訂閱者(服務(wù)S2和S3)；反之不投遞.

2.2 RocketMQ 事務(wù)型消息隊(duì)列

RocketMQ 是一個(gè)具有低延時(shí)、高并發(fā)、高可用、高可靠等特點(diǎn)的分布式消息中間件,可作為各個(gè)微服務(wù)、平臺(tái)、應(yīng)用之間的通用服務(wù),還可完成異步解耦功能,即擋住前端(消息發(fā)送方)的數(shù)據(jù)洪峰,保證后端服務(wù)的穩(wěn)定性[15],而對(duì)于事務(wù)消息,主要是通過(guò)消息的異步處理,可以保證本地事務(wù)和消息發(fā)送同時(shí)成功執(zhí)行或失敗,從而保證數(shù)據(jù)的最終一致性,RocketMQ事務(wù)型消息隊(duì)列主要流程如圖3所示.

圖3 RocketMQ 事務(wù)型消息隊(duì)列處理流程

(1)生產(chǎn)者(選課服務(wù)S1)同步發(fā)送prepare 事務(wù)消息到broker；

(2) broker 接收到消息后,將該消息進(jìn)行轉(zhuǎn)換并寫入Half Topic,寫入成功后會(huì)給生產(chǎn)者返回成功狀態(tài)；

(3)生產(chǎn)者(選課服務(wù)S1)獲取到該消息的事務(wù)Id,進(jìn)行本地事務(wù)處理；

(4)本地事務(wù)執(zhí)行成功提交Commit,若失敗則提交Rollback,提交超時(shí)或Unknow 狀態(tài)則會(huì)觸發(fā)broker的事務(wù)回查；

(5)若提交Commit 或Rollback 狀態(tài),則Broker 將消息寫入到OpTopic,該Topic 的作用主要記錄已經(jīng)Commit 或Rollback 的prepare 消息,Broker 利用Half Topic和OpTopic 計(jì)算出需回查的事務(wù)消息.如果是Commit 消息,broker 還會(huì)將消息從Half 取出來(lái)存儲(chǔ)到Topic 里,從而消費(fèi)者可正常進(jìn)行消費(fèi),如果是Rollback則不進(jìn)行其他操作；

(6)如果本地事務(wù)執(zhí)行超時(shí)或返回Unknow 狀態(tài),則broker 會(huì)進(jìn)行事務(wù)回查.若生產(chǎn)者執(zhí)行本地事務(wù)超過(guò)6 s 則進(jìn)行第一次事務(wù)回查,總共回查15 次,后續(xù)回查間隔時(shí)間是60 s,broker 在每次回查時(shí)會(huì)將消息在Half Topic 中再寫1 次.

(7)執(zhí)行事務(wù)回查時(shí),生產(chǎn)者可獲取事務(wù)Id,檢查該事務(wù)在本地執(zhí)行情況,返回狀態(tài)同第1 次執(zhí)行本地事務(wù)一樣.

RocketMQ 消息隊(duì)列事務(wù)型消息一次成功投遞需經(jīng)3 個(gè)Topic,Half Topic 用于記錄所有的prepare 消息,Op Half Topic 記錄已經(jīng)提交了狀態(tài)的prepare 消息,Real Topic 事務(wù)消息真正Topic,在Commit 后會(huì)將消息寫入該Topic,進(jìn)行消息的投遞.

從上述流程可以看到事務(wù)消息保證了生產(chǎn)者發(fā)送消息成功與本地執(zhí)行事務(wù)的成功的一致性,消費(fèi)者在消費(fèi)事務(wù)消息時(shí),broker 處理事務(wù)消息的消費(fèi)與普通消息是一樣的,若消費(fèi)不成功,則broker 會(huì)重復(fù)投遞該消息[16].

3 實(shí)現(xiàn)及應(yīng)用分析

建立RocketMQ 消息服務(wù),選課業(yè)務(wù)(S1)作為消息生產(chǎn)者,消息服務(wù)(M1)為選課服務(wù)和通知服務(wù)、統(tǒng)計(jì)服務(wù)提供中間件,通知服務(wù)(S2)和和通知服務(wù)(S3)作為消息消費(fèi)者角色存在.

3.1 事務(wù)型消息生產(chǎn)者

選課業(yè)務(wù)作為消息生產(chǎn)者,主要完成本地選課業(yè)務(wù)保存、選課消息產(chǎn)生、提供事務(wù)回查方法.選課業(yè)務(wù)回查方法可以根據(jù)由RocketMQ 回傳的key 去數(shù)據(jù)庫(kù)查詢,判斷這條數(shù)據(jù)到底是成功還是失敗.關(guān)鍵代碼如下：

3.2 事務(wù)型消息消費(fèi)

以通知服務(wù)(S3)為例說(shuō)明,設(shè)計(jì)事務(wù)型消息消費(fèi)者關(guān)鍵代碼：

3.3 冪等性設(shè)計(jì)

本文中選課業(yè)務(wù)作為微服務(wù)架構(gòu)設(shè)計(jì),如果不支持冪等操作,那將會(huì)出現(xiàn)相同的選課信息多次推送給后續(xù)的服務(wù),為避免上述情況出現(xiàn),可將通知服務(wù)和統(tǒng)計(jì)服務(wù)設(shè)計(jì)為冪等操作,冪等的接口實(shí)際上就是可以重復(fù)調(diào)用,每次接口調(diào)用的結(jié)果都是一樣的.

冪等設(shè)計(jì)具體實(shí)現(xiàn)方法：將選課的課程編號(hào)與學(xué)號(hào)作為組合主鍵,建立一張去重表,并且把上述主鍵標(biāo)識(shí)作為唯一索引,實(shí)現(xiàn)時(shí),把選課信息寫入去去重表,放在一個(gè)事務(wù)中,如果重復(fù)創(chuàng)建,數(shù)據(jù)庫(kù)會(huì)拋出唯一約束異常,操作就會(huì)回滾.

3.4 應(yīng)用分析

在實(shí)現(xiàn)分布式數(shù)據(jù)一致性時(shí),尤其是微服務(wù)之間數(shù)據(jù)一致性,為了提高并發(fā)性和可用性,更多選擇采用數(shù)據(jù)最終一致性方法,在上述分析選課業(yè)務(wù)中,選課微服務(wù)S1 成功完成選課操作,并不會(huì)直接在本地事務(wù)中完成對(duì)統(tǒng)計(jì)服務(wù)S2和通知服務(wù)S3 的調(diào)用,而是采用異步的方式通過(guò)消息隊(duì)列完成,達(dá)到最終數(shù)據(jù)的一致性,即S1 完成操作,S2和S3 收到消息.

使用事務(wù)型消息隊(duì)列解決數(shù)據(jù)一致性問(wèn)題時(shí),關(guān)鍵點(diǎn)在于：當(dāng)消息隊(duì)列收不到事務(wù)型消息的 “提交 or回滾” 消息時(shí),如何確保數(shù)據(jù)一致性.在分布式網(wǎng)絡(luò)架構(gòu)中,不可避免會(huì)出現(xiàn)網(wǎng)絡(luò)閃短、消息隊(duì)列服務(wù)短時(shí)間內(nèi)不可用等情況,會(huì)導(dǎo)致消息隊(duì)列中消息長(zhǎng)期處于Half Topic 狀態(tài),這也是消息隊(duì)列提供“事務(wù)型消息” 特性必須解決的問(wèn)題,如果消息隊(duì)列沒(méi)有收到 “提交 or回滾”消息,則無(wú)法決定是否投遞消息到消息訂閱者,此時(shí)消息隊(duì)列會(huì)主動(dòng)詢問(wèn)消息生產(chǎn)者(選課服務(wù)S1)詢問(wèn)該消息的最終狀態(tài)(Commit 或是Rollback),該過(guò)程稱為事務(wù)型消息狀態(tài)回查,具體設(shè)計(jì)方案如圖4.

圖4 消息隊(duì)列事務(wù)回查

消息隊(duì)列事務(wù)型消息基于“二階段”消息實(shí)現(xiàn),通過(guò)事務(wù)型消息狀態(tài)回查方法,即使當(dāng)消息隊(duì)列沒(méi)有收到 “提交 or 回滾”消息,也能保證事務(wù)型消息是否投遞與消息發(fā)布者本地事務(wù)狀態(tài)保持一致；在使用消息隊(duì)列解決數(shù)據(jù)一致性問(wèn)題時(shí),還需要解決消息重復(fù)投遞的問(wèn)題,通用方法是在消費(fèi)消息的微服務(wù)(S2和S3)實(shí)現(xiàn)冪等性,相同的選課消息至多只會(huì)被處理一次,后續(xù)的調(diào)用都將返回第一次調(diào)用時(shí)的處理結(jié)果.

4 結(jié)束語(yǔ)

本文總結(jié)了在處理分布式計(jì)算(微服務(wù))數(shù)據(jù)一致性問(wèn)題遵循的原則,分析實(shí)現(xiàn)微服務(wù)的冪等性設(shè)計(jì)的重要性,提出了一種采用事務(wù)型消息隊(duì)列解決分布式微服務(wù)典型應(yīng)用場(chǎng)景中數(shù)據(jù)一致性問(wèn)題的方法,并給出RocketMQ 消息隊(duì)列工作模式,分析了事務(wù)型消息隊(duì)列實(shí)現(xiàn)數(shù)據(jù)一致性的原理與實(shí)現(xiàn)方式；使用事務(wù)型消息隊(duì)列在處理分布式微服務(wù)數(shù)據(jù)一致性,事務(wù)消息消費(fèi)端的消費(fèi)方式和普通消息相同,RocketMQ 能保證消息能被消費(fèi)端收到(消息重試等機(jī)制),采用事務(wù)型消息方法還需保證消息能夠最終消費(fèi)成功這個(gè)關(guān)鍵步驟,同時(shí)微服務(wù)在消費(fèi)消息時(shí),首先要保證后續(xù)業(yè)務(wù)(S2和S3) 具有冪等性,如果consumer 消費(fèi)失敗時(shí),RocketMQ 需要人工介入處理,盡管這種情況出現(xiàn)概率極低.