分布式關系型數據庫研究與金融行業應用①

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

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

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

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

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

1 架構

在架構設計上,本文的分布式數據庫由調度節點、數據節點和配置節點構成,如圖1所示.其中,數據節點基于MySQL 集群方案,負責數據存儲、本地事務管理、本地結果集計算等功能,Grid 調度節點負責全局事務管理、分布式執行計劃的生成和調度、集群擴縮容以及數據節點的高可用調度等功能,而配置節點基于Zookeeper[10]實現,負責集群運行態元數據的存儲同步以及配置管理.

圖1 分布式數據庫架構

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

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

配置節點層主要用來存儲調度層元數據,提供調度節點的“領導選舉”.

除了上述提到的組件,本文也在數據庫安全上做了相應支持,通過黑白名單檢查、登錄認證和ACL 認證等保護數據庫安全.

下面的章節本文將會對調度層SQL 引擎、事務和鎖的實現、存儲層實現和高可用等作更深入的闡述.

2 調度

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

2.1 SQL 引擎

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

圖2 SQL 執行過程

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

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

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

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

(4) 當涉及到多個數據分片,查詢會并行下發到多個數據分片進行并行計算.

(5) 根據執行計劃對并行計算的結果集進行歸并.

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

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

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

圖3 并行查詢

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

圖4 跨節點JOIN

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

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

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

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

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

(5) 執行SELECT 計劃2.

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

2.2 事務與鎖

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

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

在鎖的支持上,Grid 實現了與MySQL 一致的支持,LOCK TABLE 會導致隱式提交,而DDL 語句導致事務的隱式提交,同時支持顯式行鎖以及FLUSH TABLE全局鎖.

3 存儲

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

Raft 作為經典的共識算法,在2014 由Ongaro 根據Paxos 算法簡化而來[8],Raft 通過領導選舉機制、日志復寫和安全性機制保證集群節點在狀態轉換間的一致.除了對原有的算法實現外,本文在具體的算法細節上也做了相應增強,在實現上與Raft 算法中元素的對應關系如表1所示.

表1 Raft 算法對應實現

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

圖5 類Raft 增強一致性算法

4 高可用

在分布式數據庫的設計上,本文通過全組件的冗余設計,保障了數據庫系統的高可用.在調度節點通過LVS 或F5 對外提供服務,而調度節點本身基于配置節點進行分布式領導選舉,保證節點可用性.數據節點的高可用保證通過采用類Raft 增強一致性同步協議實現.配置節點基于Zookeeper 實現了原生高可靠的支持,支持雙機房切換恢復.

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

圖6 高可用

數據節點的高可用通過MySQL 數據庫集群,使用類Raft 增強一致性算法實現單節點宕機后其他節點也能正常提供服務,保障高可用,同時也保證了節點間數據的一致,具體實現細節在存儲一節有介紹.

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

5 實驗與應用

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

圖7 TPMC 1000 倉庫

從圖7可以看出,本文的分布式數據庫在3 節點的集群上每分鐘最高可以達到110 w 的事務處理,隨著節點的數的增加,事務處理能力也線性上升,在6 節點集群中事務處理可以達到每分鐘220 w,橫向擴展比大于0.95.證明了該數據庫在性能上以及擴展上的優秀表現.

目前,分布式數據庫已經在國內某銀行業務系統中使用,經過技術方案、前期業務功能試點,該系統全部繳費業務單元已經逐步遷移到分布式數據庫系統中.

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

經過對分布式數據庫實際運行中的測試,銀行業務系統在聯機同步交易單筆查詢和繳費響應的時間小于100 ms,在可用性方面,系統整體可用率達到99.99%,并且數據不易丟失和損壞.相較于原有數據庫系統,現有分布式數據庫有更靈活的擴展能力,集群可動態擴展,各個功能節點發生故障可實時切換,系統發生故障的次數也大幅度下降.

6 結論

本文研究并實現了基于Raft 的增強一致性算法和Zookeeper 集群調度的分布式數據庫系統,通過全節點的冗余設計以及調度層對SQL 引擎和分布式事務的研究實現,為大規模金融數據的高可用以及強一致性提供了有力支持.在數據庫測試中表現出了優異的性能,在實際金融業務系統的穩定運行也表明該系統在金融行業應用的優勢.不過,本文的分布式數據庫在設計與實現上也有不足之處,比如限于研發難度使用多種一致性算法,增加了運維難度,后續會在這方面進一步改進.