一種基于云的應用層容錯機制設計與實現

于翔，葉德建

?

一種基于云的應用層容錯機制設計與實現

于翔，葉德建

摘 要：針對高一致性應用的場景，基于云平臺中間件提供的支持，從業務特性出發，設計了一種與數據層異步復制技術相結合的應用層容錯機制，該機制保存狀態數據的快照，在數據層異常時對未達到最終一致的狀態數據進行訪問控制，并允許其他狀態數據繼續進行業務操作。實驗證明，該機制在保證數據一致的前提下，有效縮短了系統的故障切換時間，提高了系統整體的可用性，并對系統吞吐量不造成太大影響。

關鍵詞：云平臺中間件容錯機制一致性；可用性

0 引言

分布式關系型數據庫是云存儲的重要組成部分，目前其主流架構是基于非共享存儲的主從式分庫分表結構，基于業務特征進行分庫分表使其具備良好的水平擴展能力，同一分庫通過主從復制技術實現數據冗余，并通過主備切換保證高可用性。

CAP理論指出，對于具有分區容錯性的分布式系統，可用性和一致性不可兼得[1]。其中，可用性是以系統服務的可用時間來衡量，如99.999%可用的系統在一年內服務不可用時間不超過5分鐘[2]；一致性是指數據各副本之間保持一致，對于“單點寫、多點讀”的主從式架構而言，分為強一致性和最終一致性[3]。

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

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

1 云平臺中間件支持

傳統的應用系統設計一般分為應用層和數據層，應用層負責執行業務邏輯，數據層負責業務數據模型的存儲。隨著云計算技術的發展，云中間件作為基礎支撐技術為應用層提供了強大的功能支持和穩定性保證。下面對計費系統應用層容錯機制所需的基礎中間件進行介紹：

（1）可靠消息隊列RocketMQ

RocketMQ是阿里巴巴開源的分布式可靠消息隊列，利用磁盤順序讀寫快的特性，持久化存儲消息，支持集群并發消費，吞吐量高，保證每條消息至少成功消費一次，消費失敗的消息存儲在重試隊列中，RocketMQ定時掃描該隊列進行重試消費，直至消費者返回成功。

RocketMQ提供兩階段事務性消息機制，允許應用層同時操作關系型數據庫和消息隊列。在數據庫事務中發送消息分為兩個階段：一階段發送Prepared消息，該消息存儲在隊列中，但不會被投遞給消費者；二階段是在事務結束后，根據事務結果發送Commit或Rollback消息，表示確認或取消發送。如果Prepared消息在指定時間間隔內未收到確認或取消命令，RocketMQ會將該消息發送給生產者進行回查，生產者查詢消息對應的數據庫事務執行結果并重新發送Commit或Rollback消息。RocketMQ通過兩階段消息與回查機制有效地防止懸掛消息的產生。

（2）分布式內存集群緩存Memcache

Memcache是基于一致哈希算法的分布式緩存中間件，存儲的數據結構為鍵值對，允許設置數據的過期時間，數據保存在內存中，讀寫速度快，集群中的節點構成分布式哈希表，當某個節點不可用時，相鄰節點代替該節點進行讀寫操作，但不可用節點上的數據會丟失，即在同一個集群內沒有數據的備份，冗余備份可通過將數據寫入多個集群的方式來實現。

Memcache對外操作接口均為原子性方法并提供加鎖機制控制同一鍵值對的并發操作：Add方法在主鍵沖突時保證只有一條數據插入成功，控制并發插入；Gets和Cas（compare and set）方法通過樂觀鎖機制控制并發更新，Gets方法返回數據項的當前值及其對應的唯一標識，該標識在數據項每次更新后會改變，客戶端使用Cas方法更新數據時，需要將之前Gets方法獲取到的標識作為參數傳入，如果該參數與數據項當前唯一標識相等則進行更新，否則更新失敗。

（3）應用程序管控平臺JManage

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

（4）分布式定時任務Quartz

Quartz是開源的Java定時任務調度框架，支持集群部署，具備線性擴展性和高可用性。當集群部署時，單節點執行調度任務，其余節點檢測該任務執行是否成功，如果執行失敗，新的節點會重新執行任務，直至執行成功，節點之間的互斥機制可通過對臨界資源加鎖而實現。

2 整體流程

計費系統的核心業務數據模型包括當前計費金額和計費明細。當前計費金額會隨著用戶的請求而持續改變，且不會有終止狀態，屬于狀態數據；計費明細是在每次用戶請求時新插入到數據庫中，且插入之后該條明細不再改變，其目的主要用于用戶查詢和對賬，屬于流水數據。從業務特點可以看出，狀態數據的更新強依賴于上次更新后的數值，而流水數據的插入與已有的流水數據并無關聯。當數據層主庫故障時，只要能夠獲取當前計費金額的準確值，就可以繼續進行正常的業務操作，即使用戶暫時無法查詢到最新的明細記錄，此時可在客戶端給予用戶安撫提示。因此，應用層容錯機制是針對狀態數據而設計的，在保證狀態數據一致的提前下，提高狀態數據的可用性。

應用層容錯機制將程序的運行過程劃分為4種模式：正常模式、容錯過渡模式、容錯模式和恢復模式。4種模式在程序中用變量的不同取值表示，通過JManage管控平臺切換應用層當前的運行模式，四種模式的切換順序如圖1所示：

圖1　應用層服務器的運行模式轉移順序

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

2.1 正常模式

正常模式對應主庫正常工作階段，該模式下事務操作均在主庫中進行。事務中包含的數據庫操作分為兩部分：更新狀態數據和插入流水數據。事務操作成功后，將狀態數據封裝為消息發送到RocketMQ，消費端接收消息并將狀態數據寫入多份緩存，備庫從主庫異步復制數據。正常模式的系統執行邏輯如圖2所示：

圖2　正常模式下系統執行邏輯圖

主庫數據異步復制到兩個備庫：一個備庫用于在主庫不可用時進行主備切換；另一個備庫用于讀寫分離。Memcache緩存數據的過期時間要遠大于主備庫復制延遲，從而保證緩存過期失效的數據已經復制到備庫，主備庫異步復制的延遲在幾秒鐘到十幾分鐘的范圍內，Memcache數據緩存過期時間設置為2小時，同時對主備庫復制延遲進行監控，延遲過高時報警。數據庫和分布式緩存中的狀態數據均有由應用服務器統一標記的時間戳，以便查詢最新的狀態數據。備庫和Memcache二者所有的狀態數據與主庫數據保持最終一致性，而RocketMQ中未被消費的消息則是未達到最終一致的狀態數據。

2.2 容錯過渡模式

當運維腳本通過心跳機制檢測到主庫不可用時，首先將自動調用JManage管控平臺的API接口切換應用服務器到容錯過渡模式，該模式不允許事務操作，只允許數據查詢。切換完成后，運維腳本再從集群中隨機選擇一臺應用服務器，調用其RPC接口以生成黑名單。所謂黑名單是指尚未達到最終一致的狀態數據，不允許這些數據在后續的容錯模式下進行事務處理。通過RocketMQ提供的查詢接口從消息隊列中查詢消費進度和未被消費的消息，并將查詢結果中包含的狀態數據插入到容錯庫中，可生成黑名單列表。過渡模式系統執行邏輯如圖3所示：

圖3　容錯過渡模式下系統執行邏輯圖

容錯過渡模式是四種模式中唯一不允許進行業務處理的模式，應用層處于該模式下的時間長短決定了整體系統的可用性高低，當檢測到主庫不可用時，模式切換與黑名單生成均由運維腳本調用相關接口自動完成。由于RocketMQ并發消費吞吐量高和緩存寫入速度快，因此只有少數狀態數據被記入黑名單。

2.3 容錯模式

當黑名單生成結束后，運維腳本調用JManage管控平臺的API接口切換應用服務器到容錯模式。由于未達到最終一致的狀態數據均已記入黑名單中，因此黑名單之外的狀態數據可以通過備庫和Memcache查詢到準確的最新值。將該值插入到容錯庫中，對該狀態數據的相關事務操作均在容錯庫中進行。容錯模式的系統執行邏輯如圖4所示：

圖4　容錯模式下系統執行邏輯圖

在容錯模式進行業務處理的同時，DBA等運維人員采用傳統方式進行主備切換。容錯模式與主備切換相結合的優勢在于，在主備切換的過程中，系統服務不被中斷，這也彌補了異步復制在保證一致性的提前下主備切換時間較長的缺陷。

2.4 恢復模式

當主備切換完成后，主庫重新可用，運維人員通過JManage提供的操作界面手動將應用層從容錯模式切換到恢復模式，此時主庫和容錯庫均允許進行事務操作，同時異步執行分布式定時任務，將容錯庫的狀態數據和流水數據回遷到主庫。

回遷時要準確控制事務操作的數據源，防止單條狀態數據同時在主庫和容錯庫進行更新，導致數據紊亂。對容錯庫中不存在的狀態數據或已回遷到主庫的狀態數據，在主庫進行事務操作；對未開始回遷的狀態數據，在容錯庫進行事務操作；對正在回遷的狀態數據，不允許進行事務操作。當容錯庫所有數據回遷完成，運維人員切換應用服務器到正常模式，歷史數據清空或遷移到歷史庫。恢復模式的系統執行邏輯如圖5所示：

圖5　恢復模式下系統執行邏輯圖

對應用層四種模式的總結，任何模式下進行的事務操作，均發送包含狀態數據的消息到RocketMQ，保證Memcache始終有狀態數據的最新快照，如表1所示：

表1　各模式下組件執行操作概覽表

系統整體的容錯機制在保留了數據層異步復制優點的同時，使用容錯模式在主備切換的過程中進行業務處理，系統的不可用時間也從異步復制的主備切換時長縮短為過渡模式下黑名單生成時長，前者為保證一致性需要DBA手動操作時間較長，而后者完全由運維腳本自動化快速完成，從而大大縮短了系統服務的不可用時間，提高了系統可用性。

3 模塊設計與實現

應用層容錯機制分為3個模塊：業務處理模塊、快照處理模塊和數據回遷模塊。各模塊間的交互關系如圖6所示：

圖6　容錯機制模塊交互圖

業務處理模塊負責響應不同模式下的業務處理請求，在主庫或容錯庫中進行事務操作，其運行模式通過JManage管控平臺進行切換。當運維腳本通過心跳檢測到主庫不可用時，自動切換到容錯過渡模式下，并向業務處理模塊發送請求生成黑名單，生成結束后，運維腳本切換業務處理模塊到容錯模式，開始容錯模式下的業務處理，直至主備切換完成。之后，再由運維人員切換業務處理模塊到恢復模式，并開始數據回遷，回遷是在數據回遷模塊中由Quartz定時任務異步執行，回遷結束后，運維人員切換回正常模式下。恢復模式和正常模式在切換前后均可以進行正常的業務處理，因此運維人員手動切換模式對系統可用性并無影響。

業務處理模塊進行事務處理時，將狀態數據的快照發送給快照處理模塊，并由快照處理模塊將狀態數據寫入Memcache，當在容錯模式下進行事務操作時，快照處理模塊從Memcache和備庫中讀取最新的快照返回給業務處理模塊。

在設計具有高一致性需求的其他應用系統時，應考慮在應用層設計容錯機制，并與數據層的復制技術結合起來，將容錯作為系統的整體任務，而非數據層的單一職責。根據系統的業務特點，對數據模型進行分析，選擇更新操作較為頻繁的狀態數據保存其快照，以用于容錯階段的查詢。下面對計費系統容錯機制各模塊的實現方法進行詳細介紹。

3.1 數據模型

計費系統及其容錯機制的數據模型如表2所示：

表2　計費系統數據模型表

計費表和流水表分別對應業務操作的狀態數據和流水數據，存儲于主庫和容錯庫中；狀態消息是計費金額發生變動時發送到RocketMQ的賬戶最新計費金額，其中，“數據源”字段表示本次計費操作發生在主庫還是容錯庫；狀態快照是以鍵值對的形式存儲在Memcache的計費賬戶當前金額。

黑名單是記錄在容錯模式下不提供服務的賬戶；容錯控制表是記錄在容錯模式和恢復模式下賬戶是否已回遷，其中，“賬戶標識”字段取值有三種：INIT表示賬戶在容錯庫進行事務操作；PROCESS表示賬戶正在從容錯庫回遷主庫，不允許事務操作；COMPLETE表示賬戶在主庫進行事務操作。黑名單和容錯控制表存儲于容錯庫中。

各數據模型中的“計費賬戶”字段和“計費流水號”字段在業務上是唯一的，因此在數據庫中要滿足唯一性約束。3.2 業務處理模塊

業務處理模塊負責響應用戶請求執行計費操作以及在過渡模式下生成黑名單，計費操作分為準備階段和事務處理階段。

（1）準備階段

準備階段是在事務處理前進行與當前運行模式相關的準備工作。正常模式和容錯過渡模式的準備工作較為簡單：正常模式下選擇主庫作為后續事務處理階段的數據源；容錯過渡階段拒絕一切事務處理請求。

在容錯模式下，首先查詢請求操作的計費賬戶是否在容錯控制表中，如果不存在，說明該賬戶從未在容錯模式下進行事務處理，此時，再查詢該賬戶是否在黑名單中，如果仍不存在，說明該賬戶可以在容錯模式下進行事務處理，這種情況下，業務處理模塊從快照處理模塊讀取該賬戶的最新計費金額，并插入到容錯庫的計費表中，并再向容錯庫的容錯控制表插入賬戶標識為INIT的相應記錄，兩次插入在同一事務中進行，最后選擇容錯庫作為下一階段的數據源。在容錯模式下，處理對該賬戶的后續請求時，由于容錯控制表中已經存在標識為INIT的該賬戶記錄，因此可直接選取容錯庫作為數據源，而無需再次讀取快照。

在恢復模式下，先查詢計費賬戶是否在容錯控制表中：如果存在，則根據賬戶標識選擇數據源，INIT標識選擇容錯庫，COMPLETE標識選擇主庫，PROCESS標識表示數據正在回遷，不允許操作；如果計費賬戶不在容錯控制表中，說明該賬戶在容錯模式下沒有發生計費操作，向容錯庫的容錯控制表插入賬戶標識為COMPLETE的記錄，并選擇主庫作為數據源。

當準備階段完成后，系統已經根據應用層當前的運行模式和容錯控制表中的賬戶標識選擇了對應的數據源，對三者之間的對應關系進行了總結，如表3所示：

表3　運行模式、賬戶標識和數據源對應關系表

（2）事務處理階段

事務處理階段分為四步：賬戶加鎖、對應關系檢查、數據庫操作和消息發送。

為了控制事務的并發操作，在修改任何賬戶相關的數據前，均要在計費表中對該賬戶加鎖，使用select…for update語句為單行數據加更新鎖，賬戶相關數據包括當前計費金額和賬戶標識。

在對賬戶成功加鎖后，要對運行模式、賬戶標識和已選擇數據源三者的關系進行重新檢查。再次檢查的原因有兩方面：首先，在準備階段和事務處理階段應用層運行模式可能發生了切換；其次，準備階段沒有加鎖操作，賬戶標識在查詢后可能被其他事務更新。

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

在數據庫事務提交前，需要發送計費賬戶的快照到消息隊列中，消息體中包含的內容如表2所示。事務提交前，發送一階段消息，事務提交后，根據事務提交的結果，發送二階段消息。當RocketMQ由于懸掛消息而主動回查業務處理模塊時，業務處理模塊可根據計費流水號查詢事務是否已提交，如果回查消息中的計費流水號對應的明細在數據庫中存在，并且消息體中的流水創建時間和發生額與數據庫中的記錄相同，則發送Commit消息，否則發送Rollback消息，如果此時數據庫不可用則發送Unknown消息表示要求RocketMQ稍后重新回查。消息體中的“數據源”字段表示該事務在主庫還是在容錯庫中進行，業務處理模塊根據“數據源”選擇不同的數據庫進行回查。

（3）黑名單生成

業務處理模塊對外提供黑名單生成接口，該接口的實現是從RocketMQ中查詢未消費消息，并將消息中涉及到的賬戶插入到容錯庫的黑名單中。RocketMQ中未消費的消息分為三類：消費隊列中還未投遞到快照處理模塊的消息；消費失敗后在重試隊列中等待定時重試的消息；事務性消息狀態表中還未收到二階段確認的消息。

3.3 快照處理模塊

快照處理模塊負責賬戶快照的讀寫，該模塊從RocketMQ接收消息寫入Memcache，并在容錯模式下從Memcache和備庫中讀取最新的賬戶計費金額。

當快照處理模塊讀取賬戶最新計費金額時，首先從多個Memcache集群中讀取，比較多個查詢結果的修改時間，選擇修改時間最新的結果，如果Memcache中沒有該賬戶的記錄，則從備庫中讀取，并返回結果。

當快照處理模塊接收消息寫入數據時，采用并發消費的方式以提高吞吐量，RocketMQ批量推送消息到消費者，消費者不必等待前一條消息處理完成，即可開始下一條消息的處理，單條消息消費失敗不阻塞隊列中其他消息的處理。

并發消費的方式不能保證消息嚴格有序，因此只有當消息體中計費賬戶修改時間大于Memcache中該賬戶修改時間才進行更新，否則不更新。這種做法可以保證同一計費賬戶在Memcache中是按照修改時間的先后順序進行更新的，即保證數據庫和緩存之間更新順序的因果一致性[6]。快照寫入邏輯如圖7所示：

圖7　快照處理模塊快照寫入邏輯圖

為實現快照冗余備份，快照處理模塊將數據寫入到3個Memcache集群中，寫入時構建3個任務提交到線程池中并發執行，等待并匯總3個任務的執行結果，當任務全部成功時，返回RocketMQ處理成功，否則返回處理失敗，由RocketMQ定時重試。

3.4 數據回遷模塊

在恢復模式下，由Quartz發起異步定時任務逐步將容錯庫中的數據回遷到主庫中，數據回遷的過程中涉及到容錯庫和主庫兩個數據庫的操作，由于回遷任務可能會出現異常，為保證回遷任務的可靠性，應當允許回遷任務能夠多次重試，并且多次操作不會導致同一賬戶的重復回遷，即操作要保證冪等性。

Quartz定時任務從容錯庫的容錯控制表中查詢所有賬戶標識為INIT或PROCESS的記錄，將查詢到的賬戶進行分組，并將分組發送給其他服務器，當某臺服務器接收到分組時，即開始進行該分組的回遷任務，回遷時是按照單個賬戶的維度進行的，如果某計費賬戶回遷失敗，則開始下一個賬戶的回遷。Quartz定時任務每隔一段時間重復執行，直至容錯庫的容錯控制表中所有賬戶標識均為COMPLETE。

單個計費賬戶及其相關流水的回遷邏輯如圖8所示：

圖8　回遷任務邏輯圖

回遷任務分為3個獨立的事務，其中事務1和事務2是容錯庫事務，事務3是主庫事務，如果事務2或者事務3執行失敗，則事務1回滾，而事務2和事務3是否成功只與其事務本身執行過程有關，與其他事務無關。與計費操作的事務處理類似，回遷任務需要對賬戶加更新鎖，避免并發操作。加鎖后檢測賬戶標識，標識為INIT表示沒有進行過回遷，標識為PROCESS表示上次的回遷任務沒有完成，主庫中可能已經回遷，也可能沒有回遷，標識為COMPLETE則表示回遷完成，可以結束單個賬戶的回遷任務。

為解決標識為PROCESS時無法確定是否已經回遷成功的問題，在主庫中也增加了容錯控制表，與容錯庫的容錯控制表的區別在于，主庫的容錯控制表只有COMPLETE賬戶標識，用于標識主庫回遷是否完成，該表屬于過程數據，回遷成功后刪除或者遷移到歷史數據中。容錯庫中賬戶標識為PROCESS的數據，可以依據主庫中是否存在COMPLETE標識判斷主庫的回遷是否完成，從而繼續任務的處理，即使多次重試相同的定時任務，也不會導致單個賬戶的重復回遷，保證了回遷操作的冪等性。

4 應用與測試

在基于OpenStack的私有云環境下，搭建了帶有應用層容錯機制的計費系統用于實驗測試，其計費能力通過Web服務的形式對外提供，通過發送HTTP請求可模擬真實的用戶計費操作，請求的主要參數包括計費賬戶和本次計費發生額。

私有云環境下分配的虛擬機配置相同，均為單核Intel Core i7-5500U處理器、2G內存、20G固態硬盤，操作系統均為64位CentOS6.6。應用層使用2臺虛擬機，用于搭建事務處理模塊和快照處理模塊，軟件環境為Tomcat7.0.22；數據層使用4臺虛擬機，1臺作為主庫，2臺作為備庫，1臺作為容錯庫，軟件環境為MySQL Community Server 5.7.9；為進行對比實驗，再使用4臺虛擬機搭建MySQL Cluster （NDB引擎）的同步復制環境，1臺作為管理節點，1臺作為計算節點，2臺作為存儲節點，NDB引擎的版本為7.4.8。使用InnoDB引擎的MySQL數據庫不支持同步復制，而使用NDB引擎的MySQL Cluster數據庫提供了同步復制的功能。中間件在私有云中已集群部署，作為基礎平臺為應用層提供服務，其中，RocketMQ的版本為3.2.6，Memcache的版本為1.4.4，JManage的版本為2.0，Quartz的版本為2.1.1。

測試時，首先在數據庫插入10萬條計費賬戶信息，然后利用JMeter壓測軟件模擬100個客戶端對賬戶隨機發起計費請求，測試完成后JMeter自動生成測試報告，包括吞吐量、平均響應時間等關鍵指標。

三種容錯機制的吞吐量對比測試結果如表4所示：

表4　吞吐量對比測試結果

其中異步復制和同步復制均為數據層容錯方案，未使用應用層容錯機制，測試結果表明：異步復制不影響數據庫的吞吐量，因此吞吐量最高；應用層容錯機制的額外性能開銷主要在于狀態消息的發送，其每秒處理請求數是異步復制的85%，而平均響應時間增加了24毫秒；同步復制的性能最低，其每秒處理請求數是異步復制的51.5%，性能降低一半，平均響應時間增加了131毫秒，是異步復制的兩倍。

針對應用層容錯機制在不同的吞吐量下進行故障切換的測試結果如表5所示：

表5　不同吞吐率下故障切換測試結果

結果包括故障切換時長和記入黑名單的賬戶數量。其中，故障切換時長是指處于容錯過渡模式下的時間，從切換到容錯過渡模式開始計時，當切換到容錯模式后停止計時，主要是黑名單生成時長，通過運維腳本的日志可以獲取該時間。

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

從測試結果可以看出，對于具有高一致性需求的計費系統，應用層容錯機制的故障切換時間與同步復制技術相當，系統吞吐量相對于同步復制技術則有較大提升。異步復制在保證數據一致的前提下的主備切換時長通常在分鐘級，應用層容錯機制相對于異步復制則大大縮短了故障切換時系統的不可用時間。應用層容錯機制在容錯模式下禁止黑名單賬戶的計費操作，而黑名單中賬戶數量所占比例完全在業務可接受的范圍內。

5 總結

保證數據的高可用性，不僅是DBA和運維人員的責任，同時也是應用設計者在系統架構階段應當考慮的問題。應用層容錯機制為提高系統可用性提供了一種新的思路，應用系統感知數據層的異常，并針對業務特點，制定相應的容錯階段解決方案，可有效減少系統不可用時間。

參考文獻

[1] 桑成良. 多租戶數據庫一致性問題研究[D].山東大學,2013.

[2] 梁勇. 數據庫集群故障切換技術的研究與實現[D].國防科學技術大學,2010.

[3] 施曉燁. 數據網格中副本管理策略研究[D].南京郵電大學,2011.

[4] 江英琴. 基于日志復制的醫院容災備份系統的構建與應用[D].浙江工業大學,2014.

[5] 張紅亮. 分布式系統時鐘同步技術的研究與應用[D].國防科學技術大學,2002.

[6] 呂偉. 分布式系統下時鐘同步及事件因果一致性問題研究[D].山東大學,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）

作者簡介：于 翔（1991-），男，山東，復旦大學軟件學院，碩士研究生，研究方向：分布式與云計算，上海，201203葉德建（1976-），男，浙江，復旦大學軟件學院，副教授，研究方向：網絡多媒體，上海，201203

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

中圖分類號：TP3

文獻標志碼：A