于翔，葉德建

?

一種基于云的應(yīng)用層容錯(cuò)機(jī)制設(shè)計(jì)與實(shí)現(xiàn)

于翔，葉德建

摘 要：針對(duì)高一致性應(yīng)用的場(chǎng)景，基于云平臺(tái)中間件提供的支持，從業(yè)務(wù)特性出發(fā)，設(shè)計(jì)了一種與數(shù)據(jù)層異步復(fù)制技術(shù)相結(jié)合的應(yīng)用層容錯(cuò)機(jī)制，該機(jī)制保存狀態(tài)數(shù)據(jù)的快照，在數(shù)據(jù)層異常時(shí)對(duì)未達(dá)到最終一致的狀態(tài)數(shù)據(jù)進(jìn)行訪問(wèn)控制，并允許其他狀態(tài)數(shù)據(jù)繼續(xù)進(jìn)行業(yè)務(wù)操作。實(shí)驗(yàn)證明，該機(jī)制在保證數(shù)據(jù)一致的前提下，有效縮短了系統(tǒng)的故障切換時(shí)間，提高了系統(tǒng)整體的可用性，并對(duì)系統(tǒng)吞吐量不造成太大影響。

關(guān)鍵詞：云平臺(tái)中間件容錯(cuò)機(jī)制一致性；可用性

0 引言

分布式關(guān)系型數(shù)據(jù)庫(kù)是云存儲(chǔ)的重要組成部分，目前其主流架構(gòu)是基于非共享存儲(chǔ)的主從式分庫(kù)分表結(jié)構(gòu)，基于業(yè)務(wù)特征進(jìn)行分庫(kù)分表使其具備良好的水平擴(kuò)展能力，同一分庫(kù)通過(guò)主從復(fù)制技術(shù)實(shí)現(xiàn)數(shù)據(jù)冗余，并通過(guò)主備切換保證高可用性。

CAP理論指出，對(duì)于具有分區(qū)容錯(cuò)性的分布式系統(tǒng)，可用性和一致性不可兼得[1]。其中，可用性是以系統(tǒng)服務(wù)的可用時(shí)間來(lái)衡量，如99.999%可用的系統(tǒng)在一年內(nèi)服務(wù)不可用時(shí)間不超過(guò)5分鐘[2]；一致性是指數(shù)據(jù)各副本之間保持一致，對(duì)于“單點(diǎn)寫(xiě)、多點(diǎn)讀”的主從式架構(gòu)而言，分為強(qiáng)一致性和最終一致性[3]。

文獻(xiàn)[4]指出分布式數(shù)據(jù)庫(kù)主從之間的復(fù)制技術(shù)分為同步復(fù)制和異步復(fù)制。同步復(fù)制是指一次事務(wù)操作將主備庫(kù)所有的數(shù)據(jù)副本均更新成功后返回客戶端操作成功，副本之間保持強(qiáng)一致性，當(dāng)主庫(kù)故障時(shí)，由于主備完全一致，可實(shí)現(xiàn)主備快速自動(dòng)切換，但當(dāng)備庫(kù)不可用時(shí)，事務(wù)只能回滾，因此事務(wù)成功率較低，并且由于同步復(fù)制一般采用嚴(yán)格的兩階段加鎖協(xié)議或PAXOS協(xié)議，因此系統(tǒng)的吞吐量較低，且會(huì)隨著同步副本數(shù)量的增多而進(jìn)一步降低；異步復(fù)制是指一次事務(wù)操作將主庫(kù)數(shù)據(jù)更新成功后即返回客戶端操作成功，備庫(kù)從主庫(kù)異步復(fù)制事務(wù)日志并執(zhí)行，副本之間保持最終一致性，當(dāng)備庫(kù)不可用時(shí)，事務(wù)可正常提交，異步復(fù)制的吞吐量高，且與副本數(shù)量無(wú)關(guān)，當(dāng)主庫(kù)故障時(shí)，備庫(kù)更新進(jìn)度落后于主庫(kù)，主備切換要考慮上層應(yīng)用能否接受主備數(shù)據(jù)不一致，如果能夠接受，則可實(shí)現(xiàn)快速自動(dòng)切換，否則，必須使備庫(kù)與主庫(kù)的事務(wù)日志完全相同，并等待備庫(kù)執(zhí)行日志完畢后才可切換，但主庫(kù)事務(wù)日志在主庫(kù)不可用時(shí)一般無(wú)法訪問(wèn)，因此切換難以實(shí)現(xiàn)自動(dòng)化，需要DBA手動(dòng)重啟主庫(kù)獲取日志并完成操作，切換時(shí)間大約在分鐘級(jí)。

針對(duì)高一致性的應(yīng)用場(chǎng)景，如金融、電信等行業(yè)，兩種復(fù)制技術(shù)各有不足之處，同步復(fù)制過(guò)于注重一致性而犧牲了可用性和吞吐量，異步復(fù)制的主備切換時(shí)間長(zhǎng)且需要人工干預(yù)。本文針對(duì)金融行業(yè)中常用的計(jì)費(fèi)系統(tǒng)，從業(yè)務(wù)特點(diǎn)出發(fā)，在應(yīng)用層設(shè)計(jì)了一種基于云中間件的容錯(cuò)機(jī)制，并與數(shù)據(jù)層異步復(fù)制技術(shù)相結(jié)合，當(dāng)主庫(kù)不可用需要進(jìn)行主備切換時(shí)，應(yīng)用層能夠在業(yè)務(wù)允許的范圍內(nèi)對(duì)未達(dá)到最終一致的業(yè)務(wù)數(shù)據(jù)進(jìn)行訪問(wèn)控制，并允許其他業(yè)務(wù)數(shù)據(jù)進(jìn)行正常操作，直至主備切換完成，從而在保留異步復(fù)制優(yōu)點(diǎn)的同時(shí)，極大縮短了系統(tǒng)整體的不可用時(shí)間。本文對(duì)其他具有相似需求的系統(tǒng)容錯(cuò)機(jī)制設(shè)計(jì)也給出了一般性的建議。

1 云平臺(tái)中間件支持

傳統(tǒng)的應(yīng)用系統(tǒng)設(shè)計(jì)一般分為應(yīng)用層和數(shù)據(jù)層，應(yīng)用層負(fù)責(zé)執(zhí)行業(yè)務(wù)邏輯，數(shù)據(jù)層負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)模型的存儲(chǔ)。隨著云計(jì)算技術(shù)的發(fā)展，云中間件作為基礎(chǔ)支撐技術(shù)為應(yīng)用層提供了強(qiáng)大的功能支持和穩(wěn)定性保證。下面對(duì)計(jì)費(fèi)系統(tǒng)應(yīng)用層容錯(cuò)機(jī)制所需的基礎(chǔ)中間件進(jìn)行介紹：

（1）可靠消息隊(duì)列RocketMQ

RocketMQ是阿里巴巴開(kāi)源的分布式可靠消息隊(duì)列，利用磁盤(pán)順序讀寫(xiě)快的特性，持久化存儲(chǔ)消息，支持集群并發(fā)消費(fèi)，吞吐量高，保證每條消息至少成功消費(fèi)一次，消費(fèi)失敗的消息存儲(chǔ)在重試隊(duì)列中，RocketMQ定時(shí)掃描該隊(duì)列進(jìn)行重試消費(fèi)，直至消費(fèi)者返回成功。

RocketMQ提供兩階段事務(wù)性消息機(jī)制，允許應(yīng)用層同時(shí)操作關(guān)系型數(shù)據(jù)庫(kù)和消息隊(duì)列。在數(shù)據(jù)庫(kù)事務(wù)中發(fā)送消息分為兩個(gè)階段：一階段發(fā)送Prepared消息，該消息存儲(chǔ)在隊(duì)列中，但不會(huì)被投遞給消費(fèi)者；二階段是在事務(wù)結(jié)束后，根據(jù)事務(wù)結(jié)果發(fā)送Commit或Rollback消息，表示確認(rèn)或取消發(fā)送。如果Prepared消息在指定時(shí)間間隔內(nèi)未收到確認(rèn)或取消命令，RocketMQ會(huì)將該消息發(fā)送給生產(chǎn)者進(jìn)行回查，生產(chǎn)者查詢消息對(duì)應(yīng)的數(shù)據(jù)庫(kù)事務(wù)執(zhí)行結(jié)果并重新發(fā)送Commit或Rollback消息。RocketMQ通過(guò)兩階段消息與回查機(jī)制有效地防止懸掛消息的產(chǎn)生。

（2）分布式內(nèi)存集群緩存Memcache

Memcache是基于一致哈希算法的分布式緩存中間件，存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)為鍵值對(duì)，允許設(shè)置數(shù)據(jù)的過(guò)期時(shí)間，數(shù)據(jù)保存在內(nèi)存中，讀寫(xiě)速度快，集群中的節(jié)點(diǎn)構(gòu)成分布式哈希表，當(dāng)某個(gè)節(jié)點(diǎn)不可用時(shí)，相鄰節(jié)點(diǎn)代替該節(jié)點(diǎn)進(jìn)行讀寫(xiě)操作，但不可用節(jié)點(diǎn)上的數(shù)據(jù)會(huì)丟失，即在同一個(gè)集群內(nèi)沒(méi)有數(shù)據(jù)的備份，冗余備份可通過(guò)將數(shù)據(jù)寫(xiě)入多個(gè)集群的方式來(lái)實(shí)現(xiàn)。

Memcache對(duì)外操作接口均為原子性方法并提供加鎖機(jī)制控制同一鍵值對(duì)的并發(fā)操作：Add方法在主鍵沖突時(shí)保證只有一條數(shù)據(jù)插入成功，控制并發(fā)插入；Gets和Cas（compare and set）方法通過(guò)樂(lè)觀鎖機(jī)制控制并發(fā)更新，Gets方法返回?cái)?shù)據(jù)項(xiàng)的當(dāng)前值及其對(duì)應(yīng)的唯一標(biāo)識(shí)，該標(biāo)識(shí)在數(shù)據(jù)項(xiàng)每次更新后會(huì)改變，客戶端使用Cas方法更新數(shù)據(jù)時(shí)，需要將之前Gets方法獲取到的標(biāo)識(shí)作為參數(shù)傳入，如果該參數(shù)與數(shù)據(jù)項(xiàng)當(dāng)前唯一標(biāo)識(shí)相等則進(jìn)行更新，否則更新失敗。

（3）應(yīng)用程序管控平臺(tái)JManage

JManage是基于JMX（Java Management Extensions）技術(shù)的Java應(yīng)用程序管控平臺(tái)，JMX技術(shù)可以在程序運(yùn)行時(shí)查看并動(dòng)態(tài)修改內(nèi)存變量的取值，從而動(dòng)態(tài)調(diào)整應(yīng)用程序的運(yùn)行情況，如調(diào)整線程池的最大線程數(shù)、連接池的最大連接數(shù)以及其他應(yīng)用程序的自定義變量。程序中被管理的對(duì)象稱為MBean（Managed Bean），所有MBean統(tǒng)一注冊(cè)到Java虛擬機(jī)中的MBean服務(wù)器，MBean服務(wù)器對(duì)外提供接口，JMX客戶端通過(guò)該接口查詢和更新MBean對(duì)象的屬性值。JManage管控平臺(tái)是面向集群管理的JMX客戶端，包括用戶界面和API接口，可同時(shí)滿足運(yùn)維人員手動(dòng)管理和程序自動(dòng)化管理的需求。

（4）分布式定時(shí)任務(wù)Quartz

Quartz是開(kāi)源的Java定時(shí)任務(wù)調(diào)度框架，支持集群部署，具備線性擴(kuò)展性和高可用性。當(dāng)集群部署時(shí)，單節(jié)點(diǎn)執(zhí)行調(diào)度任務(wù)，其余節(jié)點(diǎn)檢測(cè)該任務(wù)執(zhí)行是否成功，如果執(zhí)行失敗，新的節(jié)點(diǎn)會(huì)重新執(zhí)行任務(wù)，直至執(zhí)行成功，節(jié)點(diǎn)之間的互斥機(jī)制可通過(guò)對(duì)臨界資源加鎖而實(shí)現(xiàn)。

2 整體流程

計(jì)費(fèi)系統(tǒng)的核心業(yè)務(wù)數(shù)據(jù)模型包括當(dāng)前計(jì)費(fèi)金額和計(jì)費(fèi)明細(xì)。當(dāng)前計(jì)費(fèi)金額會(huì)隨著用戶的請(qǐng)求而持續(xù)改變，且不會(huì)有終止?fàn)顟B(tài)，屬于狀態(tài)數(shù)據(jù)；計(jì)費(fèi)明細(xì)是在每次用戶請(qǐng)求時(shí)新插入到數(shù)據(jù)庫(kù)中，且插入之后該條明細(xì)不再改變，其目的主要用于用戶查詢和對(duì)賬，屬于流水?dāng)?shù)據(jù)。從業(yè)務(wù)特點(diǎn)可以看出，狀態(tài)數(shù)據(jù)的更新強(qiáng)依賴于上次更新后的數(shù)值，而流水?dāng)?shù)據(jù)的插入與已有的流水?dāng)?shù)據(jù)并無(wú)關(guān)聯(lián)。當(dāng)數(shù)據(jù)層主庫(kù)故障時(shí)，只要能夠獲取當(dāng)前計(jì)費(fèi)金額的準(zhǔn)確值，就可以繼續(xù)進(jìn)行正常的業(yè)務(wù)操作，即使用戶暫時(shí)無(wú)法查詢到最新的明細(xì)記錄，此時(shí)可在客戶端給予用戶安撫提示。因此，應(yīng)用層容錯(cuò)機(jī)制是針對(duì)狀態(tài)數(shù)據(jù)而設(shè)計(jì)的，在保證狀態(tài)數(shù)據(jù)一致的提前下，提高狀態(tài)數(shù)據(jù)的可用性。

應(yīng)用層容錯(cuò)機(jī)制將程序的運(yùn)行過(guò)程劃分為4種模式：正常模式、容錯(cuò)過(guò)渡模式、容錯(cuò)模式和恢復(fù)模式。4種模式在程序中用變量的不同取值表示，通過(guò)JManage管控平臺(tái)切換應(yīng)用層當(dāng)前的運(yùn)行模式，四種模式的切換順序如圖1所示：

圖1　應(yīng)用層服務(wù)器的運(yùn)行模式轉(zhuǎn)移順序

在4種模式下涉及到的數(shù)據(jù)庫(kù)有3種：主庫(kù)、備庫(kù)和容錯(cuò)庫(kù)。主備庫(kù)之間采用異步復(fù)制技術(shù)，而容錯(cuò)庫(kù)是專用于容錯(cuò)處理時(shí)進(jìn)行事務(wù)操作的數(shù)據(jù)庫(kù)，初始化時(shí)無(wú)數(shù)據(jù)，完成容錯(cuò)任務(wù)后，容錯(cuò)庫(kù)數(shù)據(jù)清空或遷移到歷史數(shù)據(jù)庫(kù)。

2.1 正常模式

正常模式對(duì)應(yīng)主庫(kù)正常工作階段，該模式下事務(wù)操作均在主庫(kù)中進(jìn)行。事務(wù)中包含的數(shù)據(jù)庫(kù)操作分為兩部分：更新?tīng)顟B(tài)數(shù)據(jù)和插入流水?dāng)?shù)據(jù)。事務(wù)操作成功后，將狀態(tài)數(shù)據(jù)封裝為消息發(fā)送到RocketMQ，消費(fèi)端接收消息并將狀態(tài)數(shù)據(jù)寫(xiě)入多份緩存，備庫(kù)從主庫(kù)異步復(fù)制數(shù)據(jù)。正常模式的系統(tǒng)執(zhí)行邏輯如圖2所示：

圖2　正常模式下系統(tǒng)執(zhí)行邏輯圖

主庫(kù)數(shù)據(jù)異步復(fù)制到兩個(gè)備庫(kù)：一個(gè)備庫(kù)用于在主庫(kù)不可用時(shí)進(jìn)行主備切換；另一個(gè)備庫(kù)用于讀寫(xiě)分離。Memcache緩存數(shù)據(jù)的過(guò)期時(shí)間要遠(yuǎn)大于主備庫(kù)復(fù)制延遲，從而保證緩存過(guò)期失效的數(shù)據(jù)已經(jīng)復(fù)制到備庫(kù)，主備庫(kù)異步復(fù)制的延遲在幾秒鐘到十幾分鐘的范圍內(nèi)，Memcache數(shù)據(jù)緩存過(guò)期時(shí)間設(shè)置為2小時(shí)，同時(shí)對(duì)主備庫(kù)復(fù)制延遲進(jìn)行監(jiān)控，延遲過(guò)高時(shí)報(bào)警。數(shù)據(jù)庫(kù)和分布式緩存中的狀態(tài)數(shù)據(jù)均有由應(yīng)用服務(wù)器統(tǒng)一標(biāo)記的時(shí)間戳，以便查詢最新的狀態(tài)數(shù)據(jù)。備庫(kù)和Memcache二者所有的狀態(tài)數(shù)據(jù)與主庫(kù)數(shù)據(jù)保持最終一致性，而RocketMQ中未被消費(fèi)的消息則是未達(dá)到最終一致的狀態(tài)數(shù)據(jù)。

2.2 容錯(cuò)過(guò)渡模式

當(dāng)運(yùn)維腳本通過(guò)心跳機(jī)制檢測(cè)到主庫(kù)不可用時(shí)，首先將自動(dòng)調(diào)用JManage管控平臺(tái)的API接口切換應(yīng)用服務(wù)器到容錯(cuò)過(guò)渡模式，該模式不允許事務(wù)操作，只允許數(shù)據(jù)查詢。切換完成后，運(yùn)維腳本再?gòu)募褐须S機(jī)選擇一臺(tái)應(yīng)用服務(wù)器，調(diào)用其RPC接口以生成黑名單。所謂黑名單是指尚未達(dá)到最終一致的狀態(tài)數(shù)據(jù)，不允許這些數(shù)據(jù)在后續(xù)的容錯(cuò)模式下進(jìn)行事務(wù)處理。通過(guò)RocketMQ提供的查詢接口從消息隊(duì)列中查詢消費(fèi)進(jìn)度和未被消費(fèi)的消息，并將查詢結(jié)果中包含的狀態(tài)數(shù)據(jù)插入到容錯(cuò)庫(kù)中，可生成黑名單列表。過(guò)渡模式系統(tǒng)執(zhí)行邏輯如圖3所示：

圖3　容錯(cuò)過(guò)渡模式下系統(tǒng)執(zhí)行邏輯圖

容錯(cuò)過(guò)渡模式是四種模式中唯一不允許進(jìn)行業(yè)務(wù)處理的模式，應(yīng)用層處于該模式下的時(shí)間長(zhǎng)短決定了整體系統(tǒng)的可用性高低，當(dāng)檢測(cè)到主庫(kù)不可用時(shí)，模式切換與黑名單生成均由運(yùn)維腳本調(diào)用相關(guān)接口自動(dòng)完成。由于RocketMQ并發(fā)消費(fèi)吞吐量高和緩存寫(xiě)入速度快，因此只有少數(shù)狀態(tài)數(shù)據(jù)被記入黑名單。

2.3 容錯(cuò)模式

當(dāng)黑名單生成結(jié)束后，運(yùn)維腳本調(diào)用JManage管控平臺(tái)的API接口切換應(yīng)用服務(wù)器到容錯(cuò)模式。由于未達(dá)到最終一致的狀態(tài)數(shù)據(jù)均已記入黑名單中，因此黑名單之外的狀態(tài)數(shù)據(jù)可以通過(guò)備庫(kù)和Memcache查詢到準(zhǔn)確的最新值。將該值插入到容錯(cuò)庫(kù)中，對(duì)該狀態(tài)數(shù)據(jù)的相關(guān)事務(wù)操作均在容錯(cuò)庫(kù)中進(jìn)行。容錯(cuò)模式的系統(tǒng)執(zhí)行邏輯如圖4所示：

圖4　容錯(cuò)模式下系統(tǒng)執(zhí)行邏輯圖

在容錯(cuò)模式進(jìn)行業(yè)務(wù)處理的同時(shí)，DBA等運(yùn)維人員采用傳統(tǒng)方式進(jìn)行主備切換。容錯(cuò)模式與主備切換相結(jié)合的優(yōu)勢(shì)在于，在主備切換的過(guò)程中，系統(tǒng)服務(wù)不被中斷，這也彌補(bǔ)了異步復(fù)制在保證一致性的提前下主備切換時(shí)間較長(zhǎng)的缺陷。

2.4 恢復(fù)模式

當(dāng)主備切換完成后，主庫(kù)重新可用，運(yùn)維人員通過(guò)JManage提供的操作界面手動(dòng)將應(yīng)用層從容錯(cuò)模式切換到恢復(fù)模式，此時(shí)主庫(kù)和容錯(cuò)庫(kù)均允許進(jìn)行事務(wù)操作，同時(shí)異步執(zhí)行分布式定時(shí)任務(wù)，將容錯(cuò)庫(kù)的狀態(tài)數(shù)據(jù)和流水?dāng)?shù)據(jù)回遷到主庫(kù)。

回遷時(shí)要準(zhǔn)確控制事務(wù)操作的數(shù)據(jù)源，防止單條狀態(tài)數(shù)據(jù)同時(shí)在主庫(kù)和容錯(cuò)庫(kù)進(jìn)行更新，導(dǎo)致數(shù)據(jù)紊亂。對(duì)容錯(cuò)庫(kù)中不存在的狀態(tài)數(shù)據(jù)或已回遷到主庫(kù)的狀態(tài)數(shù)據(jù)，在主庫(kù)進(jìn)行事務(wù)操作；對(duì)未開(kāi)始回遷的狀態(tài)數(shù)據(jù)，在容錯(cuò)庫(kù)進(jìn)行事務(wù)操作；對(duì)正在回遷的狀態(tài)數(shù)據(jù)，不允許進(jìn)行事務(wù)操作。當(dāng)容錯(cuò)庫(kù)所有數(shù)據(jù)回遷完成，運(yùn)維人員切換應(yīng)用服務(wù)器到正常模式，歷史數(shù)據(jù)清空或遷移到歷史庫(kù)?；謴?fù)模式的系統(tǒng)執(zhí)行邏輯如圖5所示：

圖5　恢復(fù)模式下系統(tǒng)執(zhí)行邏輯圖

對(duì)應(yīng)用層四種模式的總結(jié)，任何模式下進(jìn)行的事務(wù)操作，均發(fā)送包含狀態(tài)數(shù)據(jù)的消息到RocketMQ，保證Memcache始終有狀態(tài)數(shù)據(jù)的最新快照，如表1所示：

表1　各模式下組件執(zhí)行操作概覽表

系統(tǒng)整體的容錯(cuò)機(jī)制在保留了數(shù)據(jù)層異步復(fù)制優(yōu)點(diǎn)的同時(shí)，使用容錯(cuò)模式在主備切換的過(guò)程中進(jìn)行業(yè)務(wù)處理，系統(tǒng)的不可用時(shí)間也從異步復(fù)制的主備切換時(shí)長(zhǎng)縮短為過(guò)渡模式下黑名單生成時(shí)長(zhǎng)，前者為保證一致性需要DBA手動(dòng)操作時(shí)間較長(zhǎng)，而后者完全由運(yùn)維腳本自動(dòng)化快速完成，從而大大縮短了系統(tǒng)服務(wù)的不可用時(shí)間，提高了系統(tǒng)可用性。

3 模塊設(shè)計(jì)與實(shí)現(xiàn)

應(yīng)用層容錯(cuò)機(jī)制分為3個(gè)模塊：業(yè)務(wù)處理模塊、快照處理模塊和數(shù)據(jù)回遷模塊。各模塊間的交互關(guān)系如圖6所示：

圖6　容錯(cuò)機(jī)制模塊交互圖

業(yè)務(wù)處理模塊負(fù)責(zé)響應(yīng)不同模式下的業(yè)務(wù)處理請(qǐng)求，在主庫(kù)或容錯(cuò)庫(kù)中進(jìn)行事務(wù)操作，其運(yùn)行模式通過(guò)JManage管控平臺(tái)進(jìn)行切換。當(dāng)運(yùn)維腳本通過(guò)心跳檢測(cè)到主庫(kù)不可用時(shí)，自動(dòng)切換到容錯(cuò)過(guò)渡模式下，并向業(yè)務(wù)處理模塊發(fā)送請(qǐng)求生成黑名單，生成結(jié)束后，運(yùn)維腳本切換業(yè)務(wù)處理模塊到容錯(cuò)模式，開(kāi)始容錯(cuò)模式下的業(yè)務(wù)處理，直至主備切換完成。之后，再由運(yùn)維人員切換業(yè)務(wù)處理模塊到恢復(fù)模式，并開(kāi)始數(shù)據(jù)回遷，回遷是在數(shù)據(jù)回遷模塊中由Quartz定時(shí)任務(wù)異步執(zhí)行，回遷結(jié)束后，運(yùn)維人員切換回正常模式下?；謴?fù)模式和正常模式在切換前后均可以進(jìn)行正常的業(yè)務(wù)處理，因此運(yùn)維人員手動(dòng)切換模式對(duì)系統(tǒng)可用性并無(wú)影響。

業(yè)務(wù)處理模塊進(jìn)行事務(wù)處理時(shí)，將狀態(tài)數(shù)據(jù)的快照發(fā)送給快照處理模塊，并由快照處理模塊將狀態(tài)數(shù)據(jù)寫(xiě)入Memcache，當(dāng)在容錯(cuò)模式下進(jìn)行事務(wù)操作時(shí)，快照處理模塊從Memcache和備庫(kù)中讀取最新的快照返回給業(yè)務(wù)處理模塊。

在設(shè)計(jì)具有高一致性需求的其他應(yīng)用系統(tǒng)時(shí)，應(yīng)考慮在應(yīng)用層設(shè)計(jì)容錯(cuò)機(jī)制，并與數(shù)據(jù)層的復(fù)制技術(shù)結(jié)合起來(lái)，將容錯(cuò)作為系統(tǒng)的整體任務(wù)，而非數(shù)據(jù)層的單一職責(zé)。根據(jù)系統(tǒng)的業(yè)務(wù)特點(diǎn)，對(duì)數(shù)據(jù)模型進(jìn)行分析，選擇更新操作較為頻繁的狀態(tài)數(shù)據(jù)保存其快照，以用于容錯(cuò)階段的查詢。下面對(duì)計(jì)費(fèi)系統(tǒng)容錯(cuò)機(jī)制各模塊的實(shí)現(xiàn)方法進(jìn)行詳細(xì)介紹。

3.1 數(shù)據(jù)模型

計(jì)費(fèi)系統(tǒng)及其容錯(cuò)機(jī)制的數(shù)據(jù)模型如表2所示：

表2　計(jì)費(fèi)系統(tǒng)數(shù)據(jù)模型表

計(jì)費(fèi)表和流水表分別對(duì)應(yīng)業(yè)務(wù)操作的狀態(tài)數(shù)據(jù)和流水?dāng)?shù)據(jù)，存儲(chǔ)于主庫(kù)和容錯(cuò)庫(kù)中；狀態(tài)消息是計(jì)費(fèi)金額發(fā)生變動(dòng)時(shí)發(fā)送到RocketMQ的賬戶最新計(jì)費(fèi)金額，其中，“數(shù)據(jù)源”字段表示本次計(jì)費(fèi)操作發(fā)生在主庫(kù)還是容錯(cuò)庫(kù)；狀態(tài)快照是以鍵值對(duì)的形式存儲(chǔ)在Memcache的計(jì)費(fèi)賬戶當(dāng)前金額。

黑名單是記錄在容錯(cuò)模式下不提供服務(wù)的賬戶；容錯(cuò)控制表是記錄在容錯(cuò)模式和恢復(fù)模式下賬戶是否已回遷，其中，“賬戶標(biāo)識(shí)”字段取值有三種：INIT表示賬戶在容錯(cuò)庫(kù)進(jìn)行事務(wù)操作；PROCESS表示賬戶正在從容錯(cuò)庫(kù)回遷主庫(kù)，不允許事務(wù)操作；COMPLETE表示賬戶在主庫(kù)進(jìn)行事務(wù)操作。黑名單和容錯(cuò)控制表存儲(chǔ)于容錯(cuò)庫(kù)中。

各數(shù)據(jù)模型中的“計(jì)費(fèi)賬戶”字段和“計(jì)費(fèi)流水號(hào)”字段在業(yè)務(wù)上是唯一的，因此在數(shù)據(jù)庫(kù)中要滿足唯一性約束。3.2 業(yè)務(wù)處理模塊

業(yè)務(wù)處理模塊負(fù)責(zé)響應(yīng)用戶請(qǐng)求執(zhí)行計(jì)費(fèi)操作以及在過(guò)渡模式下生成黑名單，計(jì)費(fèi)操作分為準(zhǔn)備階段和事務(wù)處理階段。

（1）準(zhǔn)備階段

準(zhǔn)備階段是在事務(wù)處理前進(jìn)行與當(dāng)前運(yùn)行模式相關(guān)的準(zhǔn)備工作。正常模式和容錯(cuò)過(guò)渡模式的準(zhǔn)備工作較為簡(jiǎn)單：正常模式下選擇主庫(kù)作為后續(xù)事務(wù)處理階段的數(shù)據(jù)源；容錯(cuò)過(guò)渡階段拒絕一切事務(wù)處理請(qǐng)求。

在容錯(cuò)模式下，首先查詢請(qǐng)求操作的計(jì)費(fèi)賬戶是否在容錯(cuò)控制表中，如果不存在，說(shuō)明該賬戶從未在容錯(cuò)模式下進(jìn)行事務(wù)處理，此時(shí)，再查詢?cè)撡~戶是否在黑名單中，如果仍不存在，說(shuō)明該賬戶可以在容錯(cuò)模式下進(jìn)行事務(wù)處理，這種情況下，業(yè)務(wù)處理模塊從快照處理模塊讀取該賬戶的最新計(jì)費(fèi)金額，并插入到容錯(cuò)庫(kù)的計(jì)費(fèi)表中，并再向容錯(cuò)庫(kù)的容錯(cuò)控制表插入賬戶標(biāo)識(shí)為INIT的相應(yīng)記錄，兩次插入在同一事務(wù)中進(jìn)行，最后選擇容錯(cuò)庫(kù)作為下一階段的數(shù)據(jù)源。在容錯(cuò)模式下，處理對(duì)該賬戶的后續(xù)請(qǐng)求時(shí)，由于容錯(cuò)控制表中已經(jīng)存在標(biāo)識(shí)為INIT的該賬戶記錄，因此可直接選取容錯(cuò)庫(kù)作為數(shù)據(jù)源，而無(wú)需再次讀取快照。

在恢復(fù)模式下，先查詢計(jì)費(fèi)賬戶是否在容錯(cuò)控制表中：如果存在，則根據(jù)賬戶標(biāo)識(shí)選擇數(shù)據(jù)源，INIT標(biāo)識(shí)選擇容錯(cuò)庫(kù)，COMPLETE標(biāo)識(shí)選擇主庫(kù)，PROCESS標(biāo)識(shí)表示數(shù)據(jù)正在回遷，不允許操作；如果計(jì)費(fèi)賬戶不在容錯(cuò)控制表中，說(shuō)明該賬戶在容錯(cuò)模式下沒(méi)有發(fā)生計(jì)費(fèi)操作，向容錯(cuò)庫(kù)的容錯(cuò)控制表插入賬戶標(biāo)識(shí)為COMPLETE的記錄，并選擇主庫(kù)作為數(shù)據(jù)源。

當(dāng)準(zhǔn)備階段完成后，系統(tǒng)已經(jīng)根據(jù)應(yīng)用層當(dāng)前的運(yùn)行模式和容錯(cuò)控制表中的賬戶標(biāo)識(shí)選擇了對(duì)應(yīng)的數(shù)據(jù)源，對(duì)三者之間的對(duì)應(yīng)關(guān)系進(jìn)行了總結(jié)，如表3所示：

表3　運(yùn)行模式、賬戶標(biāo)識(shí)和數(shù)據(jù)源對(duì)應(yīng)關(guān)系表

（2）事務(wù)處理階段

事務(wù)處理階段分為四步：賬戶加鎖、對(duì)應(yīng)關(guān)系檢查、數(shù)據(jù)庫(kù)操作和消息發(fā)送。

為了控制事務(wù)的并發(fā)操作，在修改任何賬戶相關(guān)的數(shù)據(jù)前，均要在計(jì)費(fèi)表中對(duì)該賬戶加鎖，使用select…for update語(yǔ)句為單行數(shù)據(jù)加更新鎖，賬戶相關(guān)數(shù)據(jù)包括當(dāng)前計(jì)費(fèi)金額和賬戶標(biāo)識(shí)。

在對(duì)賬戶成功加鎖后，要對(duì)運(yùn)行模式、賬戶標(biāo)識(shí)和已選擇數(shù)據(jù)源三者的關(guān)系進(jìn)行重新檢查。再次檢查的原因有兩方面：首先，在準(zhǔn)備階段和事務(wù)處理階段應(yīng)用層運(yùn)行模式可能發(fā)生了切換；其次，準(zhǔn)備階段沒(méi)有加鎖操作，賬戶標(biāo)識(shí)在查詢后可能被其他事務(wù)更新。

數(shù)據(jù)庫(kù)操作包括計(jì)費(fèi)金額的更新和流水明細(xì)的插入，在更新賬戶當(dāng)前計(jì)費(fèi)金額時(shí)，還需要更新計(jì)費(fèi)賬戶的修改時(shí)間，雖然各服務(wù)器的時(shí)間由NTP服務(wù)來(lái)統(tǒng)一，但仍會(huì)存在微小偏差，計(jì)費(fèi)賬戶的修改時(shí)間是以毫秒為單位的時(shí)間戳，如果應(yīng)用服務(wù)器當(dāng)前時(shí)間戳小于計(jì)費(fèi)賬戶上次保存的時(shí)間戳，則在計(jì)費(fèi)賬戶上次保存的時(shí)間戳的基礎(chǔ)上增加一毫秒，從而保證賬戶修改時(shí)間嚴(yán)格遞增。由于在對(duì)計(jì)費(fèi)賬戶更新時(shí)，已經(jīng)對(duì)賬戶加鎖控制事務(wù)并發(fā)，因此，通過(guò)時(shí)間戳的大小可以完全反映計(jì)費(fèi)賬戶更新的先后順序，這種做法借鑒了lamport邏輯時(shí)鐘的思想[5]。

在數(shù)據(jù)庫(kù)事務(wù)提交前，需要發(fā)送計(jì)費(fèi)賬戶的快照到消息隊(duì)列中，消息體中包含的內(nèi)容如表2所示。事務(wù)提交前，發(fā)送一階段消息，事務(wù)提交后，根據(jù)事務(wù)提交的結(jié)果，發(fā)送二階段消息。當(dāng)RocketMQ由于懸掛消息而主動(dòng)回查業(yè)務(wù)處理模塊時(shí)，業(yè)務(wù)處理模塊可根據(jù)計(jì)費(fèi)流水號(hào)查詢事務(wù)是否已提交，如果回查消息中的計(jì)費(fèi)流水號(hào)對(duì)應(yīng)的明細(xì)在數(shù)據(jù)庫(kù)中存在，并且消息體中的流水創(chuàng)建時(shí)間和發(fā)生額與數(shù)據(jù)庫(kù)中的記錄相同，則發(fā)送Commit消息，否則發(fā)送Rollback消息，如果此時(shí)數(shù)據(jù)庫(kù)不可用則發(fā)送Unknown消息表示要求RocketMQ稍后重新回查。消息體中的“數(shù)據(jù)源”字段表示該事務(wù)在主庫(kù)還是在容錯(cuò)庫(kù)中進(jìn)行，業(yè)務(wù)處理模塊根據(jù)“數(shù)據(jù)源”選擇不同的數(shù)據(jù)庫(kù)進(jìn)行回查。

（3）黑名單生成

業(yè)務(wù)處理模塊對(duì)外提供黑名單生成接口，該接口的實(shí)現(xiàn)是從RocketMQ中查詢未消費(fèi)消息，并將消息中涉及到的賬戶插入到容錯(cuò)庫(kù)的黑名單中。RocketMQ中未消費(fèi)的消息分為三類：消費(fèi)隊(duì)列中還未投遞到快照處理模塊的消息；消費(fèi)失敗后在重試隊(duì)列中等待定時(shí)重試的消息；事務(wù)性消息狀態(tài)表中還未收到二階段確認(rèn)的消息。

3.3 快照處理模塊

快照處理模塊負(fù)責(zé)賬戶快照的讀寫(xiě)，該模塊從RocketMQ接收消息寫(xiě)入Memcache，并在容錯(cuò)模式下從Memcache和備庫(kù)中讀取最新的賬戶計(jì)費(fèi)金額。

當(dāng)快照處理模塊讀取賬戶最新計(jì)費(fèi)金額時(shí)，首先從多個(gè)Memcache集群中讀取，比較多個(gè)查詢結(jié)果的修改時(shí)間，選擇修改時(shí)間最新的結(jié)果，如果Memcache中沒(méi)有該賬戶的記錄，則從備庫(kù)中讀取，并返回結(jié)果。

當(dāng)快照處理模塊接收消息寫(xiě)入數(shù)據(jù)時(shí)，采用并發(fā)消費(fèi)的方式以提高吞吐量，RocketMQ批量推送消息到消費(fèi)者，消費(fèi)者不必等待前一條消息處理完成，即可開(kāi)始下一條消息的處理，單條消息消費(fèi)失敗不阻塞隊(duì)列中其他消息的處理。

并發(fā)消費(fèi)的方式不能保證消息嚴(yán)格有序，因此只有當(dāng)消息體中計(jì)費(fèi)賬戶修改時(shí)間大于Memcache中該賬戶修改時(shí)間才進(jìn)行更新，否則不更新。這種做法可以保證同一計(jì)費(fèi)賬戶在Memcache中是按照修改時(shí)間的先后順序進(jìn)行更新的，即保證數(shù)據(jù)庫(kù)和緩存之間更新順序的因果一致性[6]?？煺諏?xiě)入邏輯如圖7所示：

圖7　快照處理模塊快照寫(xiě)入邏輯圖

為實(shí)現(xiàn)快照冗余備份，快照處理模塊將數(shù)據(jù)寫(xiě)入到3個(gè)Memcache集群中，寫(xiě)入時(shí)構(gòu)建3個(gè)任務(wù)提交到線程池中并發(fā)執(zhí)行，等待并匯總3個(gè)任務(wù)的執(zhí)行結(jié)果，當(dāng)任務(wù)全部成功時(shí)，返回RocketMQ處理成功，否則返回處理失敗，由RocketMQ定時(shí)重試。

3.4 數(shù)據(jù)回遷模塊

在恢復(fù)模式下，由Quartz發(fā)起異步定時(shí)任務(wù)逐步將容錯(cuò)庫(kù)中的數(shù)據(jù)回遷到主庫(kù)中，數(shù)據(jù)回遷的過(guò)程中涉及到容錯(cuò)庫(kù)和主庫(kù)兩個(gè)數(shù)據(jù)庫(kù)的操作，由于回遷任務(wù)可能會(huì)出現(xiàn)異常，為保證回遷任務(wù)的可靠性，應(yīng)當(dāng)允許回遷任務(wù)能夠多次重試，并且多次操作不會(huì)導(dǎo)致同一賬戶的重復(fù)回遷，即操作要保證冪等性。

Quartz定時(shí)任務(wù)從容錯(cuò)庫(kù)的容錯(cuò)控制表中查詢所有賬戶標(biāo)識(shí)為INIT或PROCESS的記錄，將查詢到的賬戶進(jìn)行分組，并將分組發(fā)送給其他服務(wù)器，當(dāng)某臺(tái)服務(wù)器接收到分組時(shí)，即開(kāi)始進(jìn)行該分組的回遷任務(wù)，回遷時(shí)是按照單個(gè)賬戶的維度進(jìn)行的，如果某計(jì)費(fèi)賬戶回遷失敗，則開(kāi)始下一個(gè)賬戶的回遷。Quartz定時(shí)任務(wù)每隔一段時(shí)間重復(fù)執(zhí)行，直至容錯(cuò)庫(kù)的容錯(cuò)控制表中所有賬戶標(biāo)識(shí)均為COMPLETE。

單個(gè)計(jì)費(fèi)賬戶及其相關(guān)流水的回遷邏輯如圖8所示：

圖8　回遷任務(wù)邏輯圖

回遷任務(wù)分為3個(gè)獨(dú)立的事務(wù)，其中事務(wù)1和事務(wù)2是容錯(cuò)庫(kù)事務(wù)，事務(wù)3是主庫(kù)事務(wù)，如果事務(wù)2或者事務(wù)3執(zhí)行失敗，則事務(wù)1回滾，而事務(wù)2和事務(wù)3是否成功只與其事務(wù)本身執(zhí)行過(guò)程有關(guān)，與其他事務(wù)無(wú)關(guān)。與計(jì)費(fèi)操作的事務(wù)處理類似，回遷任務(wù)需要對(duì)賬戶加更新鎖，避免并發(fā)操作。加鎖后檢測(cè)賬戶標(biāo)識(shí)，標(biāo)識(shí)為INIT表示沒(méi)有進(jìn)行過(guò)回遷，標(biāo)識(shí)為PROCESS表示上次的回遷任務(wù)沒(méi)有完成，主庫(kù)中可能已經(jīng)回遷，也可能沒(méi)有回遷，標(biāo)識(shí)為COMPLETE則表示回遷完成，可以結(jié)束單個(gè)賬戶的回遷任務(wù)。

為解決標(biāo)識(shí)為PROCESS時(shí)無(wú)法確定是否已經(jīng)回遷成功的問(wèn)題，在主庫(kù)中也增加了容錯(cuò)控制表，與容錯(cuò)庫(kù)的容錯(cuò)控制表的區(qū)別在于，主庫(kù)的容錯(cuò)控制表只有COMPLETE賬戶標(biāo)識(shí)，用于標(biāo)識(shí)主庫(kù)回遷是否完成，該表屬于過(guò)程數(shù)據(jù)，回遷成功后刪除或者遷移到歷史數(shù)據(jù)中。容錯(cuò)庫(kù)中賬戶標(biāo)識(shí)為PROCESS的數(shù)據(jù)，可以依據(jù)主庫(kù)中是否存在COMPLETE標(biāo)識(shí)判斷主庫(kù)的回遷是否完成，從而繼續(xù)任務(wù)的處理，即使多次重試相同的定時(shí)任務(wù)，也不會(huì)導(dǎo)致單個(gè)賬戶的重復(fù)回遷，保證了回遷操作的冪等性。

4 應(yīng)用與測(cè)試

在基于OpenStack的私有云環(huán)境下，搭建了帶有應(yīng)用層容錯(cuò)機(jī)制的計(jì)費(fèi)系統(tǒng)用于實(shí)驗(yàn)測(cè)試，其計(jì)費(fèi)能力通過(guò)Web服務(wù)的形式對(duì)外提供，通過(guò)發(fā)送HTTP請(qǐng)求可模擬真實(shí)的用戶計(jì)費(fèi)操作，請(qǐng)求的主要參數(shù)包括計(jì)費(fèi)賬戶和本次計(jì)費(fèi)發(fā)生額。

私有云環(huán)境下分配的虛擬機(jī)配置相同，均為單核Intel Core i7-5500U處理器、2G內(nèi)存、20G固態(tài)硬盤(pán)，操作系統(tǒng)均為64位CentOS6.6。應(yīng)用層使用2臺(tái)虛擬機(jī)，用于搭建事務(wù)處理模塊和快照處理模塊，軟件環(huán)境為T(mén)omcat7.0.22；數(shù)據(jù)層使用4臺(tái)虛擬機(jī)，1臺(tái)作為主庫(kù)，2臺(tái)作為備庫(kù)，1臺(tái)作為容錯(cuò)庫(kù)，軟件環(huán)境為MySQL Community Server 5.7.9；為進(jìn)行對(duì)比實(shí)驗(yàn)，再使用4臺(tái)虛擬機(jī)搭建MySQL Cluster （NDB引擎）的同步復(fù)制環(huán)境，1臺(tái)作為管理節(jié)點(diǎn)，1臺(tái)作為計(jì)算節(jié)點(diǎn)，2臺(tái)作為存儲(chǔ)節(jié)點(diǎn)，NDB引擎的版本為7.4.8。使用InnoDB引擎的MySQL數(shù)據(jù)庫(kù)不支持同步復(fù)制，而使用NDB引擎的MySQL Cluster數(shù)據(jù)庫(kù)提供了同步復(fù)制的功能。中間件在私有云中已集群部署，作為基礎(chǔ)平臺(tái)為應(yīng)用層提供服務(wù)，其中，RocketMQ的版本為3.2.6，Memcache的版本為1.4.4，JManage的版本為2.0，Quartz的版本為2.1.1。

測(cè)試時(shí)，首先在數(shù)據(jù)庫(kù)插入10萬(wàn)條計(jì)費(fèi)賬戶信息，然后利用JMeter壓測(cè)軟件模擬100個(gè)客戶端對(duì)賬戶隨機(jī)發(fā)起計(jì)費(fèi)請(qǐng)求，測(cè)試完成后JMeter自動(dòng)生成測(cè)試報(bào)告，包括吞吐量、平均響應(yīng)時(shí)間等關(guān)鍵指標(biāo)。

三種容錯(cuò)機(jī)制的吞吐量對(duì)比測(cè)試結(jié)果如表4所示：

表4　吞吐量對(duì)比測(cè)試結(jié)果

其中異步復(fù)制和同步復(fù)制均為數(shù)據(jù)層容錯(cuò)方案，未使用應(yīng)用層容錯(cuò)機(jī)制，測(cè)試結(jié)果表明：異步復(fù)制不影響數(shù)據(jù)庫(kù)的吞吐量，因此吞吐量最高；應(yīng)用層容錯(cuò)機(jī)制的額外性能開(kāi)銷主要在于狀態(tài)消息的發(fā)送，其每秒處理請(qǐng)求數(shù)是異步復(fù)制的85%，而平均響應(yīng)時(shí)間增加了24毫秒；同步復(fù)制的性能最低，其每秒處理請(qǐng)求數(shù)是異步復(fù)制的51.5%，性能降低一半，平均響應(yīng)時(shí)間增加了131毫秒，是異步復(fù)制的兩倍。

針對(duì)應(yīng)用層容錯(cuò)機(jī)制在不同的吞吐量下進(jìn)行故障切換的測(cè)試結(jié)果如表5所示：

表5　不同吞吐率下故障切換測(cè)試結(jié)果

結(jié)果包括故障切換時(shí)長(zhǎng)和記入黑名單的賬戶數(shù)量。其中，故障切換時(shí)長(zhǎng)是指處于容錯(cuò)過(guò)渡模式下的時(shí)間，從切換到容錯(cuò)過(guò)渡模式開(kāi)始計(jì)時(shí)，當(dāng)切換到容錯(cuò)模式后停止計(jì)時(shí)，主要是黑名單生成時(shí)長(zhǎng)，通過(guò)運(yùn)維腳本的日志可以獲取該時(shí)間。

測(cè)試結(jié)果表明：隨著吞吐量的增加，黑名單中的賬戶數(shù)量也增多，黑名單中賬戶數(shù)與吞吐量的比值在2.7%到6.45%的范圍內(nèi)，即黑名單中不可用賬戶數(shù)最多不超過(guò)當(dāng)前吞吐量的6.45%，絕大部分賬戶在容錯(cuò)模式下都可以進(jìn)行事務(wù)處理。應(yīng)用層容錯(cuò)機(jī)制的故障切換時(shí)間在毫秒級(jí)，根據(jù)MySQL官方提供的最新白皮書(shū)，使用NDB引擎的MySQL Cluster數(shù)據(jù)庫(kù)故障切換時(shí)間同樣在毫秒級(jí)[7]。

從測(cè)試結(jié)果可以看出，對(duì)于具有高一致性需求的計(jì)費(fèi)系統(tǒng)，應(yīng)用層容錯(cuò)機(jī)制的故障切換時(shí)間與同步復(fù)制技術(shù)相當(dāng)，系統(tǒng)吞吐量相對(duì)于同步復(fù)制技術(shù)則有較大提升。異步復(fù)制在保證數(shù)據(jù)一致的前提下的主備切換時(shí)長(zhǎng)通常在分鐘級(jí)，應(yīng)用層容錯(cuò)機(jī)制相對(duì)于異步復(fù)制則大大縮短了故障切換時(shí)系統(tǒng)的不可用時(shí)間。應(yīng)用層容錯(cuò)機(jī)制在容錯(cuò)模式下禁止黑名單賬戶的計(jì)費(fèi)操作，而黑名單中賬戶數(shù)量所占比例完全在業(yè)務(wù)可接受的范圍內(nèi)。

5 總結(jié)

保證數(shù)據(jù)的高可用性，不僅是DBA和運(yùn)維人員的責(zé)任，同時(shí)也是應(yīng)用設(shè)計(jì)者在系統(tǒng)架構(gòu)階段應(yīng)當(dāng)考慮的問(wèn)題。應(yīng)用層容錯(cuò)機(jī)制為提高系統(tǒng)可用性提供了一種新的思路，應(yīng)用系統(tǒng)感知數(shù)據(jù)層的異常，并針對(duì)業(yè)務(wù)特點(diǎn)，制定相應(yīng)的容錯(cuò)階段解決方案，可有效減少系統(tǒng)不可用時(shí)間。

參考文獻(xiàn)

[1] 桑成良. 多租戶數(shù)據(jù)庫(kù)一致性問(wèn)題研究[D].山東大學(xué),2013.

[2] 梁勇. 數(shù)據(jù)庫(kù)集群故障切換技術(shù)的研究與實(shí)現(xiàn)[D].國(guó)防科學(xué)技術(shù)大學(xué),2010.

[3] 施曉燁. 數(shù)據(jù)網(wǎng)格中副本管理策略研究[D].南京郵電大學(xué),2011.

[4] 江英琴. 基于日志復(fù)制的醫(yī)院容災(zāi)備份系統(tǒng)的構(gòu)建與應(yīng)用[D].浙江工業(yè)大學(xué),2014.

[5] 張紅亮. 分布式系統(tǒng)時(shí)鐘同步技術(shù)的研究與應(yīng)用[D].國(guó)防科學(xué)技術(shù)大學(xué),2002.

[6] 呂偉. 分布式系統(tǒng)下時(shí)鐘同步及事件因果一致性問(wèn)題研究[D].山東大學(xué),2006.

[7] Oracle, Incorporated. MySQL: A Guide to High Availability[R/OL]. Oracle, Incorporated, 2015.

Design and Implementation of Fault Tolerance Mechanism in Application Layer Based on Cloud

Yu Xiang,Ye Dejian
(1.Software School, Fudan University, Shanghai 201203, China; 2.Engineering Research Center of Cyber Security Auditing and Monitoring, Ministry of Education, Shanghai 201203, China)

Abstract:According to highly consistent scenarios, this paperproposes modular design of a fault tolerance mechanism in application layer from the perspective of business characteristicscombinedwith asynchronous replication technology in data layer based on the support provided by cloud middleware. This mechanism takes a snapshot of state data. When the data layer is down, the mechanism forbids access to the inconsistent data and allows business operation on the consistent data. Testing results show that the fault tolerance mechanism shortens the failover time effectively and improve the system’s availability under the premise of guaranteeing data consistency. At the same time, it doesn’t have an obvious impact on the system’s throughput.

Key words:Cloud Middleware; Fault Tolerance Mechanism; Consistency; Availability

收稿日期：（2015.10.14）

作者簡(jiǎn)介：于 翔（1991-），男，山東，復(fù)旦大學(xué)軟件學(xué)院，碩士研究生，研究方向：分布式與云計(jì)算，上海，201203葉德建（1976-），男，浙江，復(fù)旦大學(xué)軟件學(xué)院，副教授，研究方向：網(wǎng)絡(luò)多媒體，上海，201203

文章編號(hào)：1007-757X(2016)02-0063-06

中圖分類號(hào)：TP3

文獻(xiàn)標(biāo)志碼：A