朱哲哲,趙振海,李 鵬,吳海洋,向小佳

(光大科技有限公司,北京 100049)

數(shù)據(jù)庫的發(fā)展經(jīng)歷了從傳統(tǒng)的關(guān)系型數(shù)據(jù)庫、NoSQL (Not only SQL)[1]數(shù)據(jù)庫到近幾年新出現(xiàn)的分布式NewSQL 數(shù)據(jù)庫,整個趨勢由單機(jī)逐漸向分布式方向發(fā)展.傳統(tǒng)關(guān)系型數(shù)據(jù)庫的問題在于,對可擴(kuò)展性以及高可用性的支持不足,單機(jī)數(shù)據(jù)庫容量有限,單表容量有限,無法支撐龐大的數(shù)據(jù)查詢處理需求.一種解決辦法是通過分庫分表將負(fù)載分散到多個表中,緩解數(shù)據(jù)庫壓力,或者增加磁盤和CPU 容量,但不能從根本上解決問題.而NoSQL 數(shù)據(jù)庫雖然原生支持?jǐn)U展性和高可用性,數(shù)據(jù)模型更加靈活,但是對數(shù)據(jù)的強(qiáng)一致性卻無法保證,不支持原子事務(wù)(原子事務(wù)保證了跨多個節(jié)點事務(wù)操作的一致性,但是節(jié)點間協(xié)調(diào)會增加延時,基于性能原因的考慮,當(dāng)前NoSQL實現(xiàn)的都是基于單一鍵的事務(wù)),而且NoSQL 不兼容傳統(tǒng)的SQL 語法,造成原有系統(tǒng)的遷移障礙.分布式NewSQL 數(shù)據(jù)庫的概念產(chǎn)生來源于Google 于2012年發(fā)表的Spanner[2]數(shù)據(jù)庫,該論文將傳統(tǒng)關(guān)系模型以及NoSQL 數(shù)據(jù)庫的擴(kuò)展性相結(jié)合,使數(shù)據(jù)庫同時支持分布式又具有傳統(tǒng)SQL的能力.除了Spanner 數(shù)據(jù)庫,國外的CockroachDB[3]以及國內(nèi)的TDSQL、MyCAT、TiDB[4]、OceanBase等都是新興的分布式數(shù)據(jù)庫產(chǎn)品.分布式數(shù)據(jù)庫從實現(xiàn)上可以分為兩類:一類是在現(xiàn)有數(shù)據(jù)庫之上以中間件代理的形式,提供自動分庫分表、故障切換、分布式事務(wù)等支持,以MyCAT、TDSQL 等為代表.一類是原生的分布式架構(gòu),通過共識算法實現(xiàn)高可用性和數(shù)據(jù)一致性等支持,以TiDB、OceanBase 等為代表.

分布式數(shù)據(jù)庫常見的特點包括高可用、高可擴(kuò)展和數(shù)據(jù)強(qiáng)一致性等.對于可用性和數(shù)據(jù)一致性,根據(jù)分布式CAP[5]理論可知,在保證分區(qū)容錯性的前提下,勢必要在數(shù)據(jù)一致性和可用性中做出權(quán)衡.其中可用性的保證可以通過復(fù)制實現(xiàn),通過在多臺機(jī)器上保存數(shù)據(jù)副本,提高系統(tǒng)可用性,MyCAT 以及TDSQL 均支持主從復(fù)制的方式.傳統(tǒng)主從復(fù)制方式的問題在于雖然保證了可用性,但是數(shù)據(jù)的強(qiáng)一致性卻無法保證,如果主庫故障,可能會出現(xiàn)多個節(jié)點成為主庫(腦裂問題[6]),導(dǎo)致數(shù)據(jù)丟失或損壞.MySQL 在5.7 版本推出了MySQL Group Replication 功能,實現(xiàn)了基于Paxos 共識算法[7]的可用性和數(shù)據(jù)一致性保證,TiDB 基于Raft 共識算法[8]保證了可用性和數(shù)據(jù)一致性.擴(kuò)展性的保證可通過分區(qū)的方式,將原有單個節(jié)點的壓力分散到多個節(jié)點,提升系統(tǒng)性能.分區(qū)面臨的問題是如何將數(shù)據(jù)和查詢負(fù)載均勻分布在各個節(jié)點,常見的解決辦法有基于Hash 的分區(qū)和基于Range 的分區(qū),TiDB 使用Range的方式分區(qū),而OceanBase 兩種都支持.分布式數(shù)據(jù)庫的另一個特點是對事務(wù)的支持,分布式場景下保障事務(wù)的ACID 原則常見的辦法有2PC 協(xié)議、TCC 協(xié)議以及SAGA 協(xié)議,TiDB、OceanBase 等均使用2PC[9](兩階段提交協(xié)議)來實現(xiàn)跨多個節(jié)點的事務(wù)提交.除了對以上特點的支持,分布式數(shù)據(jù)庫還具有HTAP、SQL引擎、兼容性等特點.

對金融行業(yè)來說,在數(shù)據(jù)庫系統(tǒng)可用性、數(shù)據(jù)一致性、交易延時等方面有更嚴(yán)格的要求,系統(tǒng)可用性要求99.99%以上,賬務(wù)交易對事務(wù)要求零容忍.本文基于國內(nèi)某銀行原有金融業(yè)務(wù)的分布式改造進(jìn)行研究,銀行原有數(shù)據(jù)庫架構(gòu)采用Oracle RAC 部署的方式,這種方式的問題在于硬件成本高昂,無法有效橫向擴(kuò)展,隨著業(yè)務(wù)量的增大,系統(tǒng)性能以及存儲能力嚴(yán)重不足,故障切換時間長,更無法實現(xiàn)秒級切換,導(dǎo)致系統(tǒng)運行風(fēng)險增大.基于銀行業(yè)務(wù)對數(shù)據(jù)強(qiáng)一致性、高可用、橫向擴(kuò)展等要求,并結(jié)合銀行自身業(yè)務(wù)系統(tǒng)的特點,本文在MySQL 集群作為數(shù)據(jù)節(jié)點的基礎(chǔ)上,利用自研的調(diào)度組件Grid,實現(xiàn)了具有高可用、動態(tài)擴(kuò)展、分布式事務(wù)、HTAP 混合、兼容MySQL 等特性的分布式關(guān)系型數(shù)據(jù)庫.該數(shù)據(jù)庫通過類Raft 增強(qiáng)一致性算法和Zookeeper 自動選主實現(xiàn)了整個系統(tǒng)組件的高可用,并通過Grid 組件調(diào)度,實現(xiàn)了自動分庫分表、SQL 路由、分布式事務(wù)等功能的支持.

1 架構(gòu)

在架構(gòu)設(shè)計上,本文的分布式數(shù)據(jù)庫由調(diào)度節(jié)點、數(shù)據(jù)節(jié)點和配置節(jié)點構(gòu)成,如圖1所示.其中,數(shù)據(jù)節(jié)點基于MySQL 集群方案,負(fù)責(zé)數(shù)據(jù)存儲、本地事務(wù)管理、本地結(jié)果集計算等功能,Grid 調(diào)度節(jié)點負(fù)責(zé)全局事務(wù)管理、分布式執(zhí)行計劃的生成和調(diào)度、集群擴(kuò)縮容以及數(shù)據(jù)節(jié)點的高可用調(diào)度等功能,而配置節(jié)點基于Zookeeper[10]實現(xiàn),負(fù)責(zé)集群運行態(tài)元數(shù)據(jù)的存儲同步以及配置管理.

圖1 分布式數(shù)據(jù)庫架構(gòu)

在數(shù)據(jù)節(jié)點的實現(xiàn)上,與TiDB 以及OceanBase 等分布式數(shù)據(jù)庫不同的是,本文使用了MySQL 集群的方案.MySQL5.7 版本之前,實現(xiàn)高可用一般的做法是主從復(fù)制的方式,常利用半同步保證節(jié)點間數(shù)據(jù)的一致,但仍無法滿足高可用的要求[11].本文采用了基于Raft實現(xiàn)的增強(qiáng)一致性算法(將在第3 節(jié)存儲中詳細(xì)闡述),通過增強(qiáng)Raft 算法的部分細(xì)節(jié)實現(xiàn),提供數(shù)據(jù)庫集群節(jié)點的強(qiáng)一致保證,解決了傳統(tǒng)主從復(fù)制容易出現(xiàn)的腦裂問題.

調(diào)度節(jié)點Grid 主要用來進(jìn)行SQL 解析,實現(xiàn)分布式的SQL 語句執(zhí)行優(yōu)化.對于混合事務(wù)分析處理(HTAP)[12]的需求,除了原生支持分布式事務(wù)之外,對于在線分析處理需求,通過插件的形式提供Spark SQL 集成,將復(fù)雜語句通過SQL 引擎路由到Spark 端處理分析,而Spark 的數(shù)據(jù)則直接通過數(shù)據(jù)節(jié)點進(jìn)行抽取.對于分布式事務(wù)的實現(xiàn),采用了兩階段提交協(xié)議的標(biāo)準(zhǔn)實現(xiàn)——XA 事務(wù).本文的分布式數(shù)據(jù)庫中所有組件都是高可用和高擴(kuò)展的,以調(diào)度節(jié)點為例,在對外服務(wù)中利用F5提供負(fù)載均衡支持[13],組件本身基于配置節(jié)點實現(xiàn)分布式選主,實現(xiàn)多活高可靠.

配置節(jié)點層主要用來存儲調(diào)度層元數(shù)據(jù),提供調(diào)度節(jié)點的“領(lǐng)導(dǎo)選舉”.

除了上述提到的組件,本文也在數(shù)據(jù)庫安全上做了相應(yīng)支持,通過黑白名單檢查、登錄認(rèn)證和ACL 認(rèn)證等保護(hù)數(shù)據(jù)庫安全.

下面的章節(jié)本文將會對調(diào)度層SQL 引擎、事務(wù)和鎖的實現(xiàn)、存儲層實現(xiàn)和高可用等作更深入的闡述.

2 調(diào)度

為了解決大規(guī)模數(shù)據(jù)量以及高負(fù)載下的數(shù)據(jù)分布問題,本研究通過中間件的形式提供了對分庫分表、SQL引擎、事務(wù)與鎖等功能支持.調(diào)度層Grid 采用了XA兩階段事務(wù)以及對悲觀鎖和全隔離級別的支持.SQL引擎通過詞法分析對執(zhí)行語句進(jìn)行分布式改造,實現(xiàn)查詢下推和結(jié)果匯聚.

2.1 SQL 引擎

分布式場景下SQL 語句執(zhí)行[14]的一個要點是如何跨多個數(shù)據(jù)分片計算并收集結(jié)果,如何實現(xiàn)跨節(jié)點JOIN.解決方案在于通過某一種維度進(jìn)行切分操作,分步JOIN之后再將結(jié)果聚合.Grid 組件在SQL 引擎的實現(xiàn)上對語句進(jìn)行了并行改造,通過對語句添加后綴將其路由到不同的數(shù)據(jù)分片實現(xiàn)并行計算.執(zhí)行過程如圖2所示.

圖2 SQL 執(zhí)行過程

對于一個查詢語句來說,SQL 引擎首先對語句改造后生成查詢計劃,然后最大限度的將查詢下推,在多個節(jié)點進(jìn)行并行查詢計算,并進(jìn)行結(jié)果歸并.結(jié)果歸并的過程采用了流式歸并,其與數(shù)據(jù)庫原生的返回結(jié)果集的方式最為契合.流式歸并將每一次從結(jié)果集中取到的數(shù)據(jù),通過逐條獲取的方式得到正確的單條數(shù)據(jù).具體來說,一個查詢語句經(jīng)過SQL 引擎的步驟如下:

(1) 通過詞法語法解析獲取SQL 語句語義信息.

(2) 對SQL 語句進(jìn)行必要的分布式并行執(zhí)行改造.

(3) 盡可能地將查詢計算下推.

(4) 當(dāng)涉及到多個數(shù)據(jù)分片,查詢會并行下發(fā)到多個數(shù)據(jù)分片進(jìn)行并行計算.

(5) 根據(jù)執(zhí)行計劃對并行計算的結(jié)果集進(jìn)行歸并.

(6) 歸并過程盡可能采用流式歸并.

(7) 對于復(fù)雜的跨節(jié)點JOIN,通過分析語義將邏輯上獨立的子查詢塊拆分出來并行執(zhí)行.

對于上述步驟描述的并行執(zhí)行計算,Grid 在實現(xiàn)上采用了物理與邏輯結(jié)合的方式,通過物理表拆分與SQL 邏輯拆分相結(jié)合的數(shù)據(jù)分發(fā)及并行處理技術(shù),如圖3所示,實現(xiàn)在數(shù)據(jù)分布式部署和并行查詢執(zhí)行計劃兩個層面的性能優(yōu)化,相對于單數(shù)據(jù)庫實例,查詢效率提升N倍(N=邏輯拆分?jǐn)?shù)×虛擬分片數(shù)).

圖3 并行查詢

跨節(jié)點JOIN[15]作為分布式數(shù)據(jù)庫實現(xiàn)的難點之一,需要對普通表和分區(qū)表同時進(jìn)行支持,跨節(jié)點JOIN指的是多個節(jié)點的聯(lián)表查詢,比如“SELECT…FROM t1,t2 WHERE”查詢語句,涉及到兩張表以上的查詢.如何對多個節(jié)點數(shù)據(jù)多個表進(jìn)行JOIN,調(diào)度層Grid 采用的做法是通過引擎將復(fù)雜JOIN 拆分為多個子句,將子句劃分為表組(Table Group),生成執(zhí)行計劃,通過創(chuàng)建臨時表的方式進(jìn)行遷移[16],如圖4所示.以子句

圖4 跨節(jié)點JOIN

“SELECT … FROM tb1,tb2,tb3 WHERE”為例,首先會根據(jù)可以MERGE 的tb1和tb3 表生成一個表組,tb2為另一個表組,然后創(chuàng)建臨時表遷移.遷移的過程包含以下步驟:

(1) 在大表tb2 中創(chuàng)建記錄tb1,tb3 的臨時表.

(2) 生成tb1、tb3 的SELECT 計劃1 數(shù)據(jù)下推.

(3) 生成tb2 的SELECT 計劃2 同時創(chuàng)建臨時表.

(4) 執(zhí)行SELECT 計劃1 移動到tb2 中的臨時表.

(5) 執(zhí)行SELECT 計劃2.

對于普通表和分區(qū)表的JOIN,會在分區(qū)表的每一個節(jié)點創(chuàng)建臨時表,然后將普通表遷移到分區(qū)表每個節(jié)點的臨時表中,對于有等值分區(qū)列的JOIN 條件,則會將普通表按照分區(qū)表的分區(qū)算法散列到不同節(jié)點.如果子句中的表都是分區(qū)表,限制查詢WHERE 語句必須包含分區(qū)列,將表按照分區(qū)散列算法遷移到多個節(jié)點.遷移完成后,在分區(qū)節(jié)點中并行計算JOIN 結(jié)果并返回.

2.2 事務(wù)與鎖

對事務(wù)的支持是分布式數(shù)據(jù)庫和NoSQL 數(shù)據(jù)庫的一個主要區(qū)別,事務(wù)在數(shù)據(jù)庫中代表一系列操作要么全部完成,要么全部失敗[17],ACID 規(guī)定了事務(wù)操作的原子性、一致性、隔離性和持久性.在分布式情況下要保證ACID,常見的做法是使用兩階段提交算法(2PC).本文的分布式事務(wù)借鑒了XA 兩階段事務(wù)的實現(xiàn),通過事務(wù)管理器協(xié)調(diào)多節(jié)點之間的事務(wù),整個事務(wù)被分為準(zhǔn)備和提交兩個過程[18].

2PC 存在事務(wù)管理器故障導(dǎo)致數(shù)據(jù)庫節(jié)點無法獲知事務(wù)提交狀態(tài)的問題.在事務(wù)提交時,事務(wù)管理器崩潰或者網(wǎng)絡(luò)出現(xiàn)故障,而數(shù)據(jù)庫節(jié)點無法獲知當(dāng)前事務(wù)是否提交成功或者回滾,只能處于等待狀態(tài).常見做法是將事務(wù)提交或者終止的狀態(tài)寫入日志,在事務(wù)管理器恢復(fù)后,可以通過日志信息繼續(xù)事務(wù)過程.Grid 在實現(xiàn)上將分布式事務(wù)日志存儲在數(shù)據(jù)節(jié)點的元數(shù)據(jù)表中,同時提供主備數(shù)據(jù)副本支持.事務(wù)日志在數(shù)據(jù)節(jié)點中使用類Raft 增強(qiáng)一致性同步協(xié)議確保數(shù)據(jù)強(qiáng)一致(類Raft 協(xié)議的實現(xiàn)將在存儲一節(jié)詳細(xì)介紹),事務(wù)日志中包含了關(guān)聯(lián)節(jié)點的信息和提交狀態(tài),在出現(xiàn)故障時,通過關(guān)聯(lián)事務(wù)日志列表和狀態(tài)日志匯總結(jié)果計算出事務(wù)提交列表以及回滾列表,將結(jié)果應(yīng)用到對應(yīng)的節(jié)點上.

在鎖的支持上,Grid 實現(xiàn)了與MySQL 一致的支持,LOCK TABLE 會導(dǎo)致隱式提交,而DDL 語句導(dǎo)致事務(wù)的隱式提交,同時支持顯式行鎖以及FLUSH TABLE全局鎖.

3 存儲

分布式數(shù)據(jù)庫存儲層常見的方案有使用關(guān)系型數(shù)據(jù)庫(MySQL 等)和非關(guān)系型的鍵值數(shù)據(jù)庫,比如TiDB和CockroachDB 都使用鍵值數(shù)據(jù)庫RocksDB[19]作為其存儲層實現(xiàn).鍵值數(shù)據(jù)庫常見的底層存儲模型包括LSM-Tree[20]、B-Tree和Hash 模型,LevelDB 及其變種RocksDB 皆使用LSM-Tree 模型,內(nèi)存型數(shù)據(jù)庫Redis 使用的是Hash 模型,對于關(guān)系型數(shù)據(jù)庫來說,其底層存儲模型常使用B 樹或者其變種,比如MySQL使用的就是B+樹.本文在底層數(shù)據(jù)庫中使用MySQL數(shù)據(jù)庫作為數(shù)據(jù)集群,這樣可以最大限度的兼容原有MySQL 數(shù)據(jù)庫,而以TiDB 等為代表的數(shù)據(jù)庫需要在存儲層和MySQL 的兼容性方面提供轉(zhuǎn)換層,對SQL語法的兼容性也不夠好.在集群的實現(xiàn)上,原生MySQL主從復(fù)制實現(xiàn)的可用性方案有諸多問題,如果為同步復(fù)制,存在從節(jié)點失去響應(yīng)后導(dǎo)致主節(jié)點無法處理寫入操作的問題.另外主節(jié)點故障后如何選擇新的領(lǐng)導(dǎo)者(共識問題),還可能出現(xiàn)腦裂的現(xiàn)象.本文使用類Raft 的增強(qiáng)算法來保證數(shù)據(jù)的強(qiáng)一致性.

Raft 作為經(jīng)典的共識算法,在2014 由Ongaro 根據(jù)Paxos 算法簡化而來[8],Raft 通過領(lǐng)導(dǎo)選舉機(jī)制、日志復(fù)寫和安全性機(jī)制保證集群節(jié)點在狀態(tài)轉(zhuǎn)換間的一致.除了對原有的算法實現(xiàn)外,本文在具體的算法細(xì)節(jié)上也做了相應(yīng)增強(qiáng),在實現(xiàn)上與Raft 算法中元素的對應(yīng)關(guān)系如表1所示.

表1 Raft 算法對應(yīng)實現(xiàn)

在領(lǐng)導(dǎo)選舉的實現(xiàn)上,通過數(shù)據(jù)副本的復(fù)制指向關(guān)系進(jìn)行投票,領(lǐng)導(dǎo)者在任期內(nèi)的Term 通過master_version 進(jìn)行維護(hù),如果主節(jié)點發(fā)生故障,調(diào)度節(jié)點Grid會通過RequestVote RPC 進(jìn)行冗余節(jié)點探測來觸發(fā)新投票過程,在投票過半數(shù)的情況下,首先遍歷所有存活候選從節(jié)點,選取master_version 最大的節(jié)點,并且檢查候選節(jié)點是否有巨大的復(fù)制延遲,首先選擇從節(jié)點版本最新的節(jié)點作為主節(jié)點,如果無可用節(jié)點的話,則從延遲過大的節(jié)點中選擇.Raft 中主節(jié)點使用Append-Entries RPC 來向從節(jié)點同步日志和檢測從節(jié)點狀態(tài),本文的AppendEntries RPC 實現(xiàn)基于半同步復(fù)制,從節(jié)點直接對日志進(jìn)行應(yīng)用,同時基于閃回處理故障恢復(fù)節(jié)點[21,22].具體過程如圖5所示.

圖5 類Raft 增強(qiáng)一致性算法

4 高可用

在分布式數(shù)據(jù)庫的設(shè)計上,本文通過全組件的冗余設(shè)計,保障了數(shù)據(jù)庫系統(tǒng)的高可用.在調(diào)度節(jié)點通過LVS 或F5 對外提供服務(wù),而調(diào)度節(jié)點本身基于配置節(jié)點進(jìn)行分布式領(lǐng)導(dǎo)選舉,保證節(jié)點可用性.數(shù)據(jù)節(jié)點的高可用保證通過采用類Raft 增強(qiáng)一致性同步協(xié)議實現(xiàn).配置節(jié)點基于Zookeeper 實現(xiàn)了原生高可靠的支持,支持雙機(jī)房切換恢復(fù).

調(diào)度節(jié)點作為分布式數(shù)據(jù)庫的核心,依賴配置節(jié)點存儲調(diào)度信息.調(diào)度節(jié)點為主從模式,其關(guān)鍵在于主節(jié)點故障時如何在從節(jié)點中選取新的領(lǐng)導(dǎo)者,同時由于調(diào)度節(jié)點相對于數(shù)據(jù)節(jié)點不涉及業(yè)務(wù)數(shù)據(jù),只有少量元數(shù)據(jù)需要同步,因此調(diào)度節(jié)點Grid 直接使用Zookeeper中的Zab 算法[23]來保證.調(diào)度節(jié)點之上基于F5,從硬件層面保證負(fù)載均衡實現(xiàn)多活高可靠.如圖6所示.

圖6 高可用

數(shù)據(jù)節(jié)點的高可用通過MySQL 數(shù)據(jù)庫集群,使用類Raft 增強(qiáng)一致性算法實現(xiàn)單節(jié)點宕機(jī)后其他節(jié)點也能正常提供服務(wù),保障高可用,同時也保證了節(jié)點間數(shù)據(jù)的一致,具體實現(xiàn)細(xì)節(jié)在存儲一節(jié)有介紹.

除了高可用外,在擴(kuò)展性方面,系統(tǒng)中的所有節(jié)點均可動態(tài)添加和刪除,不影響系統(tǒng)運行.其中,調(diào)度節(jié)點依賴Zookeeper 同時實現(xiàn)了集群節(jié)點的動態(tài)增減,保證了整個集群吞吐性能的橫向擴(kuò)展,通過從節(jié)點的在線添加與在線刪除實現(xiàn)節(jié)點在線滾動升級.而數(shù)據(jù)節(jié)點的擴(kuò)展,同時支持邏輯和物理上的在線單調(diào)重分布.

5 實驗與應(yīng)用

為了更直觀的了解本文分布式數(shù)據(jù)庫的性能,實驗采用標(biāo)準(zhǔn)的TPC-C 數(shù)據(jù)庫基準(zhǔn),使用國產(chǎn)鯤鵬服務(wù)器集群對分布式事務(wù)性能(TPMC)進(jìn)行測試.其中,每臺鯤鵬服務(wù)器配置為泰山服務(wù)器2280 v2、兩個KunPeng920 64 核CPU、內(nèi)存64 GB、系統(tǒng)盤和數(shù)據(jù)盤分別為兩個600 GB SAS 盤、12 個800 GB SAS SSD.實驗通過控制集群節(jié)點數(shù)的增加,測試數(shù)據(jù)庫在事務(wù)處理上的性能,測試結(jié)果如圖7所示.

圖7 TPMC 1000 倉庫

從圖7可以看出,本文的分布式數(shù)據(jù)庫在3 節(jié)點的集群上每分鐘最高可以達(dá)到110 w 的事務(wù)處理,隨著節(jié)點的數(shù)的增加,事務(wù)處理能力也線性上升,在6 節(jié)點集群中事務(wù)處理可以達(dá)到每分鐘220 w,橫向擴(kuò)展比大于0.95.證明了該數(shù)據(jù)庫在性能上以及擴(kuò)展上的優(yōu)秀表現(xiàn).

目前,分布式數(shù)據(jù)庫已經(jīng)在國內(nèi)某銀行業(yè)務(wù)系統(tǒng)中使用,經(jīng)過技術(shù)方案、前期業(yè)務(wù)功能試點,該系統(tǒng)全部繳費業(yè)務(wù)單元已經(jīng)逐步遷移到分布式數(shù)據(jù)庫系統(tǒng)中.

原有數(shù)據(jù)庫經(jīng)過分布式改造之后,在架構(gòu)上更加清晰,分布式數(shù)據(jù)庫對外仍然像單機(jī)數(shù)據(jù)庫一樣提供服務(wù).在系統(tǒng)部署架構(gòu)上,采用雙機(jī)房運行的方式,利用兩臺備份服務(wù)器和兩臺逃生服務(wù)器保障數(shù)據(jù)完整,在數(shù)據(jù)節(jié)點的配置上,MySQL 集群節(jié)點采用一主一從和兩從節(jié)點分機(jī)房運行的方式,通過配置保障同機(jī)房和跨機(jī)房數(shù)據(jù)強(qiáng)一致性,調(diào)度節(jié)點各機(jī)房使用三臺服務(wù)器為系統(tǒng)提供調(diào)度保障.

經(jīng)過對分布式數(shù)據(jù)庫實際運行中的測試,銀行業(yè)務(wù)系統(tǒng)在聯(lián)機(jī)同步交易單筆查詢和繳費響應(yīng)的時間小于100 ms,在可用性方面,系統(tǒng)整體可用率達(dá)到99.99%,并且數(shù)據(jù)不易丟失和損壞.相較于原有數(shù)據(jù)庫系統(tǒng),現(xiàn)有分布式數(shù)據(jù)庫有更靈活的擴(kuò)展能力,集群可動態(tài)擴(kuò)展,各個功能節(jié)點發(fā)生故障可實時切換,系統(tǒng)發(fā)生故障的次數(shù)也大幅度下降.

6 結(jié)論

本文研究并實現(xiàn)了基于Raft 的增強(qiáng)一致性算法和Zookeeper 集群調(diào)度的分布式數(shù)據(jù)庫系統(tǒng),通過全節(jié)點的冗余設(shè)計以及調(diào)度層對SQL 引擎和分布式事務(wù)的研究實現(xiàn),為大規(guī)模金融數(shù)據(jù)的高可用以及強(qiáng)一致性提供了有力支持.在數(shù)據(jù)庫測試中表現(xiàn)出了優(yōu)異的性能,在實際金融業(yè)務(wù)系統(tǒng)的穩(wěn)定運行也表明該系統(tǒng)在金融行業(yè)應(yīng)用的優(yōu)勢.不過,本文的分布式數(shù)據(jù)庫在設(shè)計與實現(xiàn)上也有不足之處,比如限于研發(fā)難度使用多種一致性算法,增加了運維難度,后續(xù)會在這方面進(jìn)一步改進(jìn).