互聯(lián)網(wǎng)環(huán)境下分布式事務(wù)處理系統(tǒng)現(xiàn)狀與趨勢

馬鵬瑋，魏凱，姜春宇

中國信息通信研究院云計(jì)算與大數(shù)據(jù)研究所，北京　100191

1　分布式事務(wù)處理系統(tǒng)發(fā)展背景

中國互聯(lián)網(wǎng)持續(xù)快速發(fā)展，帶來了當(dāng)前信息的快速消費(fèi)以及數(shù)據(jù)的快速增長，這種優(yōu)勢為中國創(chuàng)造了巨大的信息紅利。與此同時(shí)，指數(shù)級增長的互聯(lián)網(wǎng)業(yè)務(wù)量也為背后的信息支撐系統(tǒng)帶來了巨大的壓力與挑戰(zhàn)。以阿里巴巴淘寶網(wǎng)為例，2009—2017年“雙十一”交易額如圖1所示。

圖1　淘寶網(wǎng)“雙十一”交易額

巨大交易增長量的背后，后臺信息支撐系統(tǒng)除了直接面向用戶的電商網(wǎng)站系統(tǒng)外，相關(guān)的物流系統(tǒng)、支付系統(tǒng)、倉儲系統(tǒng)、訂單系統(tǒng)等也都接受了巨大的考驗(yàn)。而上述各類信息系統(tǒng)的核心數(shù)據(jù)處理能力，幾乎均與數(shù)據(jù)處理系統(tǒng)的性能息息相關(guān)。

各類數(shù)據(jù)處理場景可以分為事務(wù)場景和非事務(wù)場景兩大類。事務(wù)場景即數(shù)據(jù)處理過程需要滿足原子性、一致性、隔離性、持久性（atomicity、consistency、isolation、durability，ACID）4個(gè)特性。典型的場景如銀行賬戶間轉(zhuǎn)賬、物流倉庫的運(yùn)輸?shù)?。非事?wù)場景對數(shù)據(jù)處理過程沒有對ACID特性的嚴(yán)格要求。典型的場景有搜索展現(xiàn)場景、報(bào)表分析場景等。

因?yàn)槭聞?wù)場景具有ACID特性，所以相比于非事務(wù)場景，事務(wù)場景對底層數(shù)據(jù)處理系統(tǒng)提出了更高的技術(shù)要求。以銀行支付系統(tǒng)為例，目前核心的支付系統(tǒng)經(jīng)過幾十年的發(fā)展，形成了采用所謂的IOE（即IBM公司的大中型服務(wù)器、Oracle公司的數(shù)據(jù)庫軟件、EMC公司的存儲設(shè)備）結(jié)構(gòu)作為事務(wù)場景的支撐系統(tǒng)。這套系統(tǒng)結(jié)構(gòu)用于支撐銀行傳統(tǒng)的柜臺業(yè)務(wù)沒有大問題，但是隨著國內(nèi)移動(dòng)互聯(lián)網(wǎng)以及電商業(yè)務(wù)的快速發(fā)展，其中存在的問題逐漸暴露。

（1）性能上限

傳統(tǒng)的IOE結(jié)構(gòu)為集中式系統(tǒng)，即所有的軟件系統(tǒng)都運(yùn)行在一個(gè)性能十分強(qiáng)大的服務(wù)器上，例如IBM公司的AS 400、AS 390等。當(dāng)業(yè)務(wù)壓力變大時(shí)，一般采用縱向擴(kuò)展（scale up）方案，即繼續(xù)增加單臺服務(wù)器的性能上限。但是隨著摩爾定律逐漸失效，靠增大壓縮器件尺寸提高單臺服務(wù)器性能上限的方案已經(jīng)逐漸失效，縱向擴(kuò)展路線即將走到盡頭。

（2）成本巨大

當(dāng)業(yè)務(wù)量上升時(shí)，不僅硬件系統(tǒng)的規(guī)模需要呈指數(shù)級增長，同時(shí)軟件系統(tǒng)相應(yīng)的服務(wù)費(fèi)用也會隨之增長，中國銀行、中國農(nóng)業(yè)銀行、中國建設(shè)銀行、中國工商銀行每年相應(yīng)的支出達(dá)到數(shù)億元，且仍在持續(xù)增長。

（3）嚴(yán)重捆綁

采用IOE結(jié)構(gòu)的公司，因?yàn)楦鳝h(huán)節(jié)信息系統(tǒng)供應(yīng)商的壟斷化及單一化，會造成嚴(yán)重的服務(wù)提供商捆綁問題。傳統(tǒng)的IOE服務(wù)提供商會對相應(yīng)功能實(shí)施生態(tài)封閉策略，造成服務(wù)消費(fèi)方對其服務(wù)的嚴(yán)重依賴，這為未來埋下了嚴(yán)重的隱患。例如IBM公司近年來市場份額逐漸下降，未來方向尚不明確，如果將來IBM公司不再提供服務(wù)器的供應(yīng)或維護(hù)，那當(dāng)前相應(yīng)的IOE體系服務(wù)消費(fèi)方將會遭受嚴(yán)重打擊。

（4）非自主化產(chǎn)品

IOE體系均為國外的技術(shù)與產(chǎn)品，這方面需要進(jìn)行自主化改造，從而掌握核心技術(shù)主動(dòng)性。

（5）適應(yīng)新業(yè)務(wù)環(huán)境

隨著業(yè)務(wù)產(chǎn)品的逐漸豐富，底層數(shù)據(jù)系統(tǒng)架構(gòu)需要增加擴(kuò)展能力，從而適應(yīng)多種業(yè)務(wù)類型的靈活性要求，而集中式架構(gòu)在這方面具有先天缺陷。

為解決以上各類問題，各大技術(shù)公司逐漸開始研發(fā)分布式事務(wù)數(shù)據(jù)系統(tǒng)技術(shù)，從而逐漸在事務(wù)場景中替代傳統(tǒng)的IOE結(jié)構(gòu)。

2　分布式事務(wù)數(shù)據(jù)處理系統(tǒng)優(yōu)勢及面臨的挑戰(zhàn)

分布式事務(wù)數(shù)據(jù)處理系統(tǒng)是利用高速通信網(wǎng)絡(luò)以及多臺服務(wù)器的分布化方式，解決數(shù)據(jù)處理事務(wù)場景的數(shù)據(jù)處理系統(tǒng)，其具有以下特性。

● 以橫向擴(kuò)展路線代替縱向擴(kuò)展路線。通過集群模式，將任務(wù)和數(shù)據(jù)分發(fā)到多臺服務(wù)器上，多臺服務(wù)器共同協(xié)作，通過增加橫向擴(kuò)展服務(wù)器的數(shù)量達(dá)到提高單臺服務(wù)器性能上限的目的，從而解決性能上限問題。

● 使用廉價(jià)服務(wù)器及開源產(chǎn)品解決成本問題。分布式事務(wù)處理系統(tǒng)在底層不再采用成本巨大的超級服務(wù)器以及專有商業(yè)事務(wù)數(shù)據(jù)庫，而是采用多臺廉價(jià)的x86服務(wù)器以及開源的數(shù)據(jù)庫產(chǎn)品達(dá)到相應(yīng)效果，預(yù)計(jì)單一企業(yè)在該方面的成本將從千萬級下降到百萬級。

● 多元化、開源化解決服務(wù)商捆綁問題。分布式事務(wù)處理系統(tǒng)可從硬件、軟件等多個(gè)環(huán)節(jié)對接業(yè)內(nèi)多種企業(yè)或開源產(chǎn)品。例如硬件支撐系統(tǒng)可以采用華為、浪潮、戴爾等多種x86服務(wù)器提供商提供的相應(yīng)產(chǎn)品，軟件支撐系統(tǒng)可以采用MySQL、MariDB、PostgreSQL等多款開源數(shù)據(jù)庫產(chǎn)品，從而解決嚴(yán)重捆綁的問題。

● 國內(nèi)企業(yè)研發(fā)解決非自主可控問題。當(dāng)前國內(nèi)涌現(xiàn)出多款自主研發(fā)分布式事務(wù)處理系統(tǒng)產(chǎn)品，例如阿里巴巴的OceanBase數(shù)據(jù)庫、騰訊的TDSQL數(shù)據(jù)庫、中興通訊的GoldenDB數(shù)據(jù)庫、PingCAP的TiDB數(shù)據(jù)庫等。這樣，可以通過國內(nèi)企業(yè)的創(chuàng)新力量解決非自主可控的問題。

理論上分布式事務(wù)數(shù)據(jù)處理系統(tǒng)橫向擴(kuò)展路線可以達(dá)到數(shù)據(jù)處理能力上限。但是為了保證事務(wù)場景ACID特性，分布式事務(wù)數(shù)據(jù)處理系統(tǒng)無法達(dá)到其理論上限。深層次的原因?yàn)榉植际绞聞?wù)數(shù)據(jù)處理系統(tǒng)在數(shù)據(jù)處理過程增加了網(wǎng)絡(luò)傳輸環(huán)節(jié)，而根據(jù)統(tǒng)計(jì)分析，數(shù)據(jù)在網(wǎng)絡(luò)中傳輸處理的速度大概為單機(jī)系統(tǒng)內(nèi)傳輸處理的千分之一，所以傳統(tǒng)事務(wù)數(shù)據(jù)處理系統(tǒng)中成熟的保證事務(wù)場景ACID的技術(shù)方案無法直接應(yīng)用到分布式事務(wù)數(shù)據(jù)處理系統(tǒng)中。

為了研究如何使分布式事務(wù)數(shù)據(jù)處理系統(tǒng)保障事務(wù)場景ACID特性的問題，學(xué)術(shù)界提出：一致性、可用性、分區(qū)容錯(cuò)性（consistency、 availability、partition tolerance，CAP）無法同時(shí)全部滿足，只能同時(shí)滿足兩個(gè)特性。通俗解釋為：為了滿足分區(qū)容錯(cuò)性，數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)需要同時(shí)保證多副本分散分布，而多副本分散分布會帶來無法保證各副本間數(shù)據(jù)一致性的問題，而嚴(yán)格保證各副本間數(shù)據(jù)一致性，又會導(dǎo)致數(shù)據(jù)庫系統(tǒng)性能下降。所以，CAP 3個(gè)特性無法同時(shí)得到滿足。

在分布式體系結(jié)構(gòu)中，分區(qū)現(xiàn)象是默認(rèn)存在的，所以分區(qū)容錯(cuò)性默認(rèn)必須得到滿足。而事務(wù)特性要求一致性必須得到滿足，所以相應(yīng)的分布式事務(wù)數(shù)據(jù)處理系統(tǒng)必須保證分區(qū)容錯(cuò)性和數(shù)據(jù)一致性，酌情降低了系統(tǒng)可用性。

同時(shí)，分布式體系結(jié)構(gòu)存儲數(shù)據(jù)的方式相對于集中式存儲系統(tǒng)存儲數(shù)據(jù)的方式來說，增加了兩種新型的擴(kuò)展形式。

第一種數(shù)據(jù)擴(kuò)展形式為數(shù)據(jù)分區(qū)處理，即“大表變小表”。當(dāng)一張表的容量達(dá)到上限或者出現(xiàn)業(yè)務(wù)交叉時(shí)，常進(jìn)行水平拆分處理，即將一張表的數(shù)據(jù)拆分成幾張表共同存儲，各表分別放在不同的服務(wù)器上，從而針對不同小表訪問的業(yè)務(wù)可以分散到不同的服務(wù)器上，減少單點(diǎn)問題，提高可用性。

第二種數(shù)據(jù)擴(kuò)展形式為數(shù)據(jù)鏡像處理，即“一份變多份”。一張表進(jìn)行數(shù)據(jù)鏡像，從而形成內(nèi)容為同一份數(shù)據(jù)的多張表，但是從物理位置上看，卻分散在不同的服務(wù)器上。針對某一份數(shù)據(jù)的業(yè)務(wù)可以分散到這份數(shù)據(jù)其余的鏡像數(shù)據(jù)服務(wù)器上，從而提升服務(wù)性能。同時(shí)，當(dāng)其中某臺服務(wù)器發(fā)生故障、無法提供服務(wù)時(shí)，它的數(shù)據(jù)鏡像所在的服務(wù)器仍然能夠提供服務(wù)，提升了分區(qū)容錯(cuò)性。

新增的數(shù)據(jù)擴(kuò)展形式在帶來優(yōu)點(diǎn)的同時(shí)，也為分布式事務(wù)性的保障提出了新的挑戰(zhàn)。

● 首先，針對數(shù)據(jù)分區(qū)擴(kuò)展形式產(chǎn)生了分布式事務(wù)中的多機(jī)協(xié)作問題。當(dāng)某個(gè)事務(wù)處理過程涉及多個(gè)分區(qū)的數(shù)據(jù)，而這多個(gè)分區(qū)的數(shù)據(jù)分散在不同的服務(wù)器上時(shí)，通過服務(wù)器之間的網(wǎng)絡(luò)通信，保證事務(wù)的ACID屬性成為挑戰(zhàn)。

● 其次，針對數(shù)據(jù)鏡像擴(kuò)展形式產(chǎn)生了分布式事務(wù)中的數(shù)據(jù)同步問題。當(dāng)某個(gè)事務(wù)針對某份數(shù)據(jù)進(jìn)行更改操作時(shí)，利用服務(wù)器間網(wǎng)絡(luò)通信使這份數(shù)據(jù)的鏡像數(shù)據(jù)與之保持同步，從而維護(hù)數(shù)據(jù)鏡像的特點(diǎn)，使對外提供服務(wù)的鏡像數(shù)據(jù)與源數(shù)據(jù)之間不會出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象，這是另一個(gè)挑戰(zhàn)。

3　分布式事務(wù)數(shù)據(jù)處理系統(tǒng)各類技術(shù)方案

數(shù)據(jù)分區(qū)擴(kuò)展形式帶來的挑戰(zhàn)通常稱為分區(qū)一致性（consistency）問題，數(shù)據(jù)鏡像擴(kuò)展形式帶來的挑戰(zhàn)通常稱為副本一致性（consensus）問題。

針對分區(qū)一致性問題，核心解決方案依然是沿襲傳統(tǒng)集中式數(shù)據(jù)庫系統(tǒng)的事務(wù)問題解決方案，即處理好事務(wù)過程中鎖與并發(fā)的控制問題。傳統(tǒng)集中式數(shù)據(jù)庫系統(tǒng)解決此問題的方式為兩階段鎖（2 phase lock，2PL）方案，即通過兩階段鎖控制本次事務(wù)涉及的資源，從而達(dá)到事務(wù)屬性。在分布式系統(tǒng)中，原有的2PL方案轉(zhuǎn)化為兩階段提交（2 phase commit，2PC）類方案，即通過分別向同一事務(wù)涉及的多臺服務(wù)器發(fā)送兩階段的提交要求，完成同步提交的效果。2PC方案根據(jù)各類事務(wù)隔離級別要求，后續(xù)又被改進(jìn)為3PC、2+XPC、異步消息隊(duì)列、TCC（try confirm cancel）方案等。目前各類應(yīng)用都是針對不同的實(shí)際業(yè)務(wù)場景，抽象出業(yè)務(wù)的實(shí)際隔離級別需求，然后在上述各種方案中選擇合適的分區(qū)一致性解決方案。

副本一致性的核心問題為分布式系統(tǒng)中的數(shù)據(jù)復(fù)制問題。由于分布式系統(tǒng)增加了網(wǎng)絡(luò)傳輸?shù)难舆t性和不確定性，一致性方案主要分為服務(wù)器邏輯架構(gòu)設(shè)計(jì)解決方案和數(shù)據(jù)自組織解決方案。常見服務(wù)器邏輯架構(gòu)解決方案設(shè)定為主從模式或者主主模式，通過掐斷數(shù)據(jù)復(fù)制過程中從服務(wù)器的數(shù)據(jù)輸出能力，達(dá)到副本一致性的目的。常見的數(shù)據(jù)及組織解決方案為Paxos、Raft、Zab等一致性算法協(xié)議，通過自由選舉、過半投票確認(rèn)、分區(qū)容錯(cuò)的解決方式自組織解決副本一致性問題。

業(yè)內(nèi)為了綜合解決上述兩個(gè)問題，從各個(gè)方向逐漸發(fā)展出了3種相應(yīng)的架構(gòu)方案。

第一種架構(gòu)方案為中間件方案，其架構(gòu)示意如圖2所示。

圖2　Cobar中間件方案架構(gòu)

整個(gè)分布式事務(wù)數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應(yīng)用層，第二層為中間件層，第三層為數(shù)據(jù)庫實(shí)例層。其中，底層數(shù)據(jù)庫實(shí)例層常采用開源的集中式數(shù)據(jù)庫，負(fù)責(zé)本實(shí)例上的數(shù)據(jù)存儲與處理；中間件層負(fù)責(zé)手動(dòng)數(shù)據(jù)分區(qū)之后的分區(qū)信息維護(hù)、上層應(yīng)用下發(fā)的SQL語句分布式解析下發(fā)、分布式事務(wù)的統(tǒng)一執(zhí)行控制等，從而實(shí)現(xiàn)數(shù)據(jù)分區(qū)與分布式事務(wù)的實(shí)現(xiàn)。

第二種架構(gòu)方案為共享存儲方案，其架構(gòu)示意如圖3所示。

圖3　Oracle RAC共享存儲方案架構(gòu)

整個(gè)分布式事務(wù)數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應(yīng)用層，第二層為數(shù)據(jù)庫計(jì)算實(shí)例層，第三層為共享存儲層。數(shù)據(jù)庫計(jì)算實(shí)例層通過分布式擴(kuò)展，保證集群的計(jì)算性能，增強(qiáng)可用性。同時(shí)共享存儲層采用新型存儲硬件結(jié)構(gòu)，保證高速I/O性能的同時(shí)，避免了存儲層數(shù)據(jù)網(wǎng)絡(luò)通信的環(huán)節(jié)，通過改進(jìn)一定量傳統(tǒng)的集中式數(shù)據(jù)庫系統(tǒng)的事務(wù)解決方案，保障了共享存儲架構(gòu)中的分布式事務(wù)能力。但是由于統(tǒng)一式存儲帶來的并發(fā)和I/O能力的理論極限，集群規(guī)模無法做到大規(guī)模擴(kuò)展。業(yè)內(nèi)實(shí)踐案例表明，當(dāng)此類解決方案集群數(shù)量達(dá)到百臺規(guī)模時(shí)，性能將會出現(xiàn)比較大的下滑。

第三種架構(gòu)方案為計(jì)算存儲均分布式擴(kuò)展方案，其架構(gòu)示意如圖4所示。

整個(gè)分布式事務(wù)數(shù)據(jù)處理系統(tǒng)架構(gòu)分為3層，最上層為應(yīng)用層，第二層為分布式計(jì)算層，第三層為分布式存儲層。分布式計(jì)算層與共享存儲方案的數(shù)據(jù)庫計(jì)算實(shí)例層相似，均通過分布式擴(kuò)展能力保證集群的計(jì)算性能，增強(qiáng)可用性。而分布式存儲層采用零共享（shared nothing）架構(gòu)，同時(shí)大部分產(chǎn)品具備自動(dòng)化分區(qū)功能，不需要人為定義分區(qū)模式，各個(gè)存儲節(jié)點(diǎn)之間通過高速互聯(lián)網(wǎng)絡(luò)進(jìn)行通信，通過一致性算法即多版本并發(fā)控制（multi-version concurrency control，MVCC）保障數(shù)據(jù)執(zhí)行過程中的集群狀態(tài)正確性以及事務(wù)的ACID屬性。但是當(dāng)存儲層分布式化之后，事務(wù)設(shè)計(jì)不同節(jié)點(diǎn)通信時(shí)，由于網(wǎng)絡(luò)時(shí)延問題，與統(tǒng)一存儲相比，事務(wù)整體執(zhí)行過程的時(shí)延勢必有一定比例的增加。

圖4　計(jì)算存儲均分布式擴(kuò)展方案架構(gòu)

最后根據(jù)新數(shù)據(jù)時(shí)代下對數(shù)據(jù)庫的功能需求，本文簡單從幾個(gè)維度對上述3類數(shù)據(jù)庫方案進(jìn)行粗略的對比和總結(jié)，對比結(jié)果見表1。

表1　3類數(shù)據(jù)庫方案對比

4　分布式事務(wù)數(shù)據(jù)處理系統(tǒng)應(yīng)用注意事項(xiàng)

分布式事務(wù)數(shù)據(jù)處理系統(tǒng)相比于集中式數(shù)據(jù)處理系統(tǒng)具有一系列優(yōu)點(diǎn)，但是在成功應(yīng)用之前，仍然需要注意幾點(diǎn)問題。

（1）正確認(rèn)識自身業(yè)務(wù)需求

分布式系統(tǒng)中的CAP決定了強(qiáng)一致性、高可用性、分區(qū)容錯(cuò)性三者不能同時(shí)實(shí)現(xiàn)。正確地認(rèn)識自身業(yè)務(wù)需求，明確當(dāng)前業(yè)務(wù)在上述3種特性中的重點(diǎn)，才能切合實(shí)際地對后續(xù)分布式事務(wù)數(shù)據(jù)處理系統(tǒng)功能做出取舍。而正確認(rèn)識業(yè)務(wù)主要是服務(wù)規(guī)模和服務(wù)質(zhì)量兩方面。例如，對于金融行業(yè)中的核心業(yè)務(wù)，服務(wù)質(zhì)量是必須滿足的，所以必須要保證強(qiáng)一致性，從而弱化高可用性。而對于互聯(lián)網(wǎng)系統(tǒng)中的查詢業(yè)務(wù)，服務(wù)規(guī)模是主要需求，所以高可用性必須保障，而一致性可以相應(yīng)地進(jìn)行弱化。

（2）明確分布式事務(wù)數(shù)據(jù)處理系統(tǒng)各產(chǎn)品特點(diǎn)及適用場景

分布式事務(wù)數(shù)據(jù)處理系統(tǒng)因?yàn)榈讓蛹夹g(shù)路線不同，所以上層適用場景也不盡相同。例如，部分分布式事務(wù)數(shù)據(jù)處理系統(tǒng)需要在管理節(jié)點(diǎn)數(shù)量大于某個(gè)數(shù)量時(shí)，才能發(fā)揮較優(yōu)性能，這就對應(yīng)用方集群規(guī)模做出了限制；部分分布式事務(wù)數(shù)據(jù)處理系統(tǒng)需要使用特殊的硬件作為存儲或計(jì)算介質(zhì)，從而達(dá)到較優(yōu)性能，這就對應(yīng)用方硬件環(huán)境做出了限制。其他的類似區(qū)別指標(biāo)有是否需要人工參與數(shù)據(jù)分區(qū)、適用的服務(wù)規(guī)模范圍、是否具備多中心容災(zāi)能力、是否能夠提供多種事務(wù)隔離級別等。

（3）正確規(guī)劃已有IT架構(gòu)向分布式體系遷移的路徑及策略

目前現(xiàn)有數(shù)據(jù)庫系統(tǒng)以集中式架構(gòu)為主，且當(dāng)前實(shí)際業(yè)務(wù)和第三方應(yīng)用大部分也是基于集中式數(shù)據(jù)庫結(jié)構(gòu)實(shí)現(xiàn)的。如何在數(shù)據(jù)庫架構(gòu)從集中式向分布式轉(zhuǎn)移過程中，保證上層業(yè)務(wù)的正常服務(wù)能力以及盡量少的原有業(yè)務(wù)體系變動(dòng)，是需要格外注意的問題。為達(dá)到此目的，首先需要對轉(zhuǎn)型后系統(tǒng)與原系統(tǒng)的兼容能力做一個(gè)充分評估，其次需要合理規(guī)劃轉(zhuǎn)型過程中存量業(yè)務(wù)和增量業(yè)務(wù)的關(guān)系，最后需要在新型系統(tǒng)正式上線前進(jìn)行充分驗(yàn)證，做好原有系統(tǒng)災(zāi)備的充足準(zhǔn)備。

（4）驗(yàn)證分布式事務(wù)數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力

在正式遷移應(yīng)用之前，需要正確篩選符合要求的分布式事務(wù)數(shù)據(jù)處理系統(tǒng)產(chǎn)品，同時(shí)驗(yàn)證各類分布式事務(wù)數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力范圍。筆者所在單位于2017年7月開始分布式事務(wù)數(shù)據(jù)處理系統(tǒng)標(biāo)準(zhǔn)化的嘗試，梳理出分布式事務(wù)數(shù)據(jù)處理系統(tǒng)基準(zhǔn)測試的方法論和具體實(shí)施方法?；鶞?zhǔn)測試主要包括功能和性能兩大方向，指標(biāo)項(xiàng)包括兼容能力、透明能力、管理能力、分布式能力、事務(wù)能力、安全能力、高可用能力、場景化性能指標(biāo)等多個(gè)維度，從而全面衡量分布式事務(wù)數(shù)據(jù)處理系統(tǒng)產(chǎn)品能力。

5　分布式事務(wù)數(shù)據(jù)處理系統(tǒng)未來趨勢

近幾年，以Google Spanner為代表的NewSQL類數(shù)據(jù)庫發(fā)展迅速，其以全球范圍內(nèi)的擴(kuò)展性、強(qiáng)事務(wù)支持能力、靈活的應(yīng)用形式、廉價(jià)的軟硬件成本等特點(diǎn)，逐漸成為數(shù)據(jù)庫的最新演進(jìn)形態(tài)，而這也是當(dāng)前信息社會環(huán)境下的必然結(jié)果。究其原因，數(shù)據(jù)庫的最初需求就是高性價(jià)比地實(shí)現(xiàn)數(shù)據(jù)的管理工作。首先高性價(jià)比可以從經(jīng)濟(jì)成本和業(yè)務(wù)成本兩方面衡量，NewSQL類數(shù)據(jù)庫實(shí)現(xiàn)了基于x86等廉價(jià)服務(wù)器搭建，并在底層實(shí)現(xiàn)數(shù)據(jù)自動(dòng)化均衡處理，對業(yè)務(wù)侵入性不高，不需要應(yīng)用過多感知，同時(shí)節(jié)約了經(jīng)濟(jì)成本和業(yè)務(wù)成本。其次，數(shù)據(jù)的管理工作分為存儲和處理兩方面。在大數(shù)據(jù)時(shí)代，數(shù)據(jù)的基本特征為數(shù)量大、類型多、價(jià)值密度低、速度快、時(shí)效高，所以對數(shù)據(jù)處理的需求為擴(kuò)展性強(qiáng)、數(shù)據(jù)兼容能力強(qiáng)、具備分析能力、處理能力強(qiáng)，而NewSQL類數(shù)據(jù)庫具備聯(lián)機(jī)分析處理（online analytical processing，OLAP）/聯(lián)機(jī)事務(wù)處理過程（on-line transaction processing，OLTP）混合能力、存儲與計(jì)算強(qiáng)擴(kuò)展性、兼容結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)等多個(gè)特點(diǎn)，切合了當(dāng)前時(shí)代數(shù)據(jù)管理功能需求。

隨著大數(shù)據(jù)、物聯(lián)網(wǎng)、人工智能等應(yīng)用的快速興起，分布式架構(gòu)取代集中式架構(gòu)是大勢所趨，未來分布式事務(wù)數(shù)據(jù)處理系統(tǒng)將會作為數(shù)據(jù)時(shí)代的技術(shù)結(jié)構(gòu)，為未來技術(shù)浪潮的發(fā)展提供更多的數(shù)據(jù)基礎(chǔ)能力，未來分布式事務(wù)數(shù)據(jù)處理系統(tǒng)將在幾個(gè)方面繼續(xù)延伸變化。

首先，分布式事務(wù)數(shù)據(jù)處理系統(tǒng)的功能形態(tài)將會更加豐富。隨著大數(shù)據(jù)和人工智能產(chǎn)業(yè)的發(fā)展，各數(shù)據(jù)應(yīng)用企業(yè)都利用自身快速增長的業(yè)務(wù)數(shù)據(jù)，擴(kuò)展出核心業(yè)務(wù)能力之外的數(shù)據(jù)分析能力，這就需要底層數(shù)據(jù)處理過程除了滿足事務(wù)型邏輯之外，分析功能需求占到越來越多的比例。數(shù)據(jù)庫作為數(shù)據(jù)底層服務(wù)設(shè)施，保障上層業(yè)務(wù)事務(wù)特性的同時(shí)提供高可用的分析能力是未來的發(fā)展趨勢。目前已有將底層存儲結(jié)構(gòu)對接上層兩套邏輯系統(tǒng)，完成上述功能的實(shí)例。未來如何平衡事務(wù)和分析兩種業(yè)務(wù)的支撐占比以及相應(yīng)技術(shù)實(shí)現(xiàn)方式，仍然需要繼續(xù)探索與實(shí)踐。

其次，新型硬件之下的分布式事務(wù)數(shù)據(jù)處理系統(tǒng)形態(tài)得到發(fā)展。底層存儲與計(jì)算硬件（如3D內(nèi)存、Flash卡、硬件壓縮卡、非易失性存儲器等）的快速發(fā)展，是原有數(shù)據(jù)庫系統(tǒng)發(fā)展過程未曾預(yù)想到的。當(dāng)前數(shù)據(jù)庫系統(tǒng)的底層讀寫模式仍是以原有磁盤存儲介質(zhì)特點(diǎn)進(jìn)行設(shè)計(jì)并發(fā)展起來的，例如事務(wù)日志刷盤模式、緩沖區(qū)大小計(jì)算方法、I/O與網(wǎng)絡(luò)的性能瓶頸評估等，這些傳統(tǒng)設(shè)計(jì)方法造成了新型硬件介質(zhì)的優(yōu)勢特點(diǎn)無法被現(xiàn)有數(shù)據(jù)庫系統(tǒng)充分應(yīng)用。未來的分布式事務(wù)數(shù)據(jù)處理系統(tǒng)需要針對新型硬件特性進(jìn)行相關(guān)研發(fā)，從而突破傳統(tǒng)數(shù)據(jù)庫的思維及認(rèn)知局限。

最后，利用協(xié)調(diào)硬件突破軟件困境。例如因?yàn)槲锢頃r(shí)鐘難以同步，所以傳統(tǒng)事務(wù)數(shù)據(jù)庫通常采用邏輯時(shí)鐘維護(hù)事務(wù)順序，但是邏輯時(shí)鐘的維護(hù)會限制數(shù)據(jù)庫的規(guī)模大小，所以覆蓋全球范圍的事務(wù)數(shù)據(jù)庫幾乎不可能實(shí)現(xiàn)。而Google公司推出的Spanner數(shù)據(jù)庫直接采用硬件GPS加上原子鐘方案，解決了物理時(shí)鐘同步問題，做到了全球范圍的數(shù)據(jù)庫事務(wù)一致性。預(yù)計(jì)未來將會出現(xiàn)更多協(xié)調(diào)硬件輔助數(shù)據(jù)庫軟件系統(tǒng)解決之前無法解決的問題。

6　結(jié)束語

IT架構(gòu)作為企業(yè)架構(gòu)的基礎(chǔ)，支撐著上層業(yè)務(wù)架構(gòu)的建設(shè)與發(fā)展，促進(jìn)了頂層愿景和戰(zhàn)略的順利實(shí)施。而傳統(tǒng)集中式事務(wù)數(shù)據(jù)處理系統(tǒng)面對新環(huán)境下OLTP業(yè)務(wù)的迅速增長，相關(guān)問題逐漸暴露，故需要完成集中式體系向分布式體系的轉(zhuǎn)型，從而釋放數(shù)據(jù)紅利，充分發(fā)展數(shù)字經(jīng)濟(jì)。而當(dāng)前分布式事務(wù)數(shù)據(jù)處理系統(tǒng)正處于快速創(chuàng)新發(fā)展時(shí)期，多種體系架構(gòu)并存，在擴(kuò)展性、性能、可用性等方面優(yōu)于傳統(tǒng)集中式數(shù)據(jù)處理系統(tǒng)，但穩(wěn)定性、服務(wù)能力等方面仍與傳統(tǒng)集中式數(shù)據(jù)處理系統(tǒng)存在差距。故在轉(zhuǎn)型過程中，應(yīng)用方需要充分掌握相關(guān)技術(shù)特點(diǎn)、應(yīng)用方法、實(shí)現(xiàn)方式等知識體系，從而實(shí)現(xiàn)快速、平穩(wěn)的轉(zhuǎn)型進(jìn)程。

參考文獻(xiàn)：

[1]CORBETT J C, DEAN J, EPSTEIN M, et al.Spanner: Google's globally-distributed database[C]//USENIX Conference on Operating Systems Design and Implementation, October 8-10, 2012,Hollywood, USA. Berkeley: USENIX Association, 2012: 251-264.

[2]CHEUNG D W, NG V T, FU A W,et al. Efficient mining of association rules in distributed databases[J]. IEEE Transactions on Knowledge & Data Engineering, 1996, 8(6): 911-922.

[3]?ZSU M T, VALDURIEZ P. Principles of distributed database systems[M]. Berlin:Springer, 1999, 24(1): 31-41.

[4]BERNSTEIN P A. Concurrency control in distributed database systems[J]. ACM Computing Surveys, 1989, 13(2): 185-221.

[5]PAIVA J, RUIVO P, Romano P, et al.AutoPlacer: scalable self-tuning data placement in distributed key-value stores[J].ACM Transactions on Autonomous &Adaptive Systems, 2014, 9(4):19.

[6]KUMAR R, GUPTA N, CHARU S, et al.Manage big data through NewSQL[C]//National Conference on Innovation in Wireless Communication and Networking Technology,April 6-9, 2014, Istanbul, Turkey.Piscataway: IEEE Press, 2014: 1-6.

[7]KUMAR R, PARASHAR B B, GUPTA S, et al.Apache Hadoop, NoSQL and NewSQL solutions of big data[J]. International Journal of Advance Foundation and Research in Science & Engineering, 2014,1(6): 28-36.

[8]ARDEKANI M S, TERRY D B. A selfconfigurable geo-replicated cloud storage system[C]//USENIX Conference on Operating Systems Design and Implementation, October 6-8, 2014,Broomfield, USA. Berkeley: USENIX Association, 2015: 367-381.

[9]LING G U, WENG H X, HUA-LIANG H U,et al. OceanBase schema design for OLAP application[J]. Journal of East China Normal University, 2014(5): 301-310.

[10]RAMANATHAN S, GOEL S,ALAGUMALAI S. Comparison of cloud database: Amazon's simpleDB and Google's bigtable[C]// International Conference on Recent Trends in Information Systems,June 3-5, 2011, Chennai, India.

[11]SUKHWANI B, MIN H, THOENNES M,et al. Database analytics acceleration using FPGAs[C]// International Conference on Parallel Architectures and Compilation Techniques, September 9-13, 2017,Portland, USA. Piscataway: IEEE Press,2017: 411-420.

[12]ABBAS Q, SHAFIQ H, AHMAD I, et al.Concurrency control in distributed database system[C]// International Conference on Computer Communication and Informatics, January 7-9, 2016,Coimbatore, India. Piscataway: IEEE Press, 2016: 1-4.