1 啥是分布式DB？

隨著TiDB等分布式DB的興起，關系型DB也逐漸增加了分布式特性。在這些分布式DB中，數(shù)據(jù)分片和分布式事務是內(nèi)置的基礎功能，使業(yè)務開發(fā)人員能夠像使用傳統(tǒng)關系型DB一樣簡便地使用JDBC接口。作為一種分布式DB中間件，shardingSphere除了提供標準化的數(shù)據(jù)分片解決方案外，還實現(xiàn)了分布式事務和DB治理功能。讓我們一起探索這些強大的工具如何提高數(shù)據(jù)管理和操作的效率！

事實標準

當一款技術產(chǎn)品占據(jù)市場主導地位時，它就成為同類產(chǎn)品的標桿。就像關系型數(shù)據(jù)庫中，Oracle成為了事實標桿，因為所有新版本的數(shù)據(jù)庫產(chǎn)品都要和Oracle進行對比，比較各自的特性。這樣一來，Oracle就擁有更多的用戶和支持，而其他競爭對手則需要不斷改進自己的產(chǎn)品才能與之匹敵。

分布式數(shù)據(jù)庫是一個新興的基礎軟件，但還沒有一款產(chǎn)品能夠成為“事實標準”。我們需要自己來定義這個概念，因為沒有現(xiàn)成的參考。為此，我們可以從內(nèi)部和外部兩個視角來觀察它，這樣可以更全面地認識它。

2 外部視角：外部特性

分布式 DB具備啥特性，能解決啥痛點。

業(yè)務應用系統(tǒng)按交易類型分類：

聯(lián)機交易（OLTP）面向交易的處理過程，單筆交易的數(shù)據(jù)量小，但是要在很短的時間內(nèi)給出結果，典型場景包括購物、繳費、轉賬等
聯(lián)機分析（OLAP）通常是基于大數(shù)據(jù)集的運算，典型場景包括生成個人年度賬單和企業(yè)財務報表等。

難有一款產(chǎn)品中完全滿足兩者，因此在單體DB時代演化出兩個不同技術體系，即兩類不同的關系型DB。向分布式架構演進后，兩者在架構設計也采用完全不同策略，很難在一個框架下說清。

先專注討論OLTP場景下的分布式 DB。本教程所提“ DB”都默認“關系型DB”，分布式DB也都指支持關系模型的分布式DB。即不討論NoSQL，整體看，關系型DB由于支持SQL、提供ACID事務，具有更好通用性，在更廣泛場景中無法被NoSQL取代。通過NoSQL十余年來發(fā)展已被證實。

分布式DB目標正是融合傳統(tǒng)關系型 DB與NoSQL DB的優(yōu)勢，而且已經(jīng)取得不錯效果。

3 定義

3.1 OLTP關系型 DB

僅用“OLTP場景”作為定語顯然不夠精準，我們來進一步看看OLTP場景具體的技術特點。

OLTP場景的通常有三個特點：

寫多讀少，指請求數(shù)量。而且讀操作的復雜度較低，一般不涉及大數(shù)據(jù)集的匯總計算
低延時，用戶對于延時的容忍度較低，通常在500毫秒以內(nèi)，稍微放大一些也就是秒級，超過5秒的延時通常是無法接受的；
高并發(fā)，并發(fā)量隨著業(yè)務量而增長，沒有理論上限。

我們是不是可以有這樣一個結論：分布式 DB是服務于寫多讀少、低延時、高并發(fā)的OLTP場景的 DB。

3.2 海量并發(fā)

你可能會說這個定義有問題，比如MySQL和Oracle這樣的關系型 DB也是服務于OLTP場景的，但它們并不是分布式 DB。

相對傳統(tǒng)關系型 DB，分布式 DB最大差異就是分布式 DB遠高于前者的并發(fā)處理能力。

傳統(tǒng)關系型 DB往往是單機模式，主要負載運行在一臺機器。DB的并發(fā)處理能力與單機的資源配置是線性相關的，所以并發(fā)處理能力的上限也就受限于單機配置的上限。這種依靠提升單機資源配置來擴展性能的方式，即垂直擴展（Scale Up）。

在一臺機器中，隨隨便便就能多塞進些CPU和內(nèi)存來提升提性能嗎？當然沒那么容易。所以，物理機單機配置上限的提升是相對緩慢的。即在一定時期內(nèi)，依賴垂直擴展的 DB總會存在性能的天花板。很多銀行采購小型機或大型機的原因之一，就是相比x86服務器，這些機器能夠安裝更多的CPU和內(nèi)存，可以把天花板推高一些。

而分布式 DB不同，在維持關系型 DB特性不變的基礎上，它通過水平擴展增加機器數(shù)量，提供遠高單體 DB的并發(fā)量。這個并發(fā)量幾乎不受單機性能限制，我將這個級別的并發(fā)量稱為“海量并發(fā)”。

“海量并發(fā)”到底多大

沒權威數(shù)字。雖然理論上是可以找一臺世界上最好的機器來測試一下，但考慮到商業(yè)因素，這個數(shù)字不會有什么實際價值。不過，我可以給出一個經(jīng)驗值，這個“海量并發(fā)”的下限大致是10,000TPS。

2.0版本的定義：分布式 DB是服務于寫多讀少、低延時、海量并發(fā)OLTP場景的關系型 DB。

3.3 +高可靠

2.0版仍有問題。是不是沒有海量并發(fā)需求，就不需要使用分布式 DB了呢？不是的，你還要考慮 DB的高可靠性。

一般來說，可靠性是與硬件設備的故障率有關的。

與銀行不同，很多互聯(lián)網(wǎng)公司和中小企業(yè)通常是采用x86服務器的。x86服務器有很多優(yōu)勢，但故障率會相對高一些，坊間流傳的年故障率在5%左右。

一些更加可靠的數(shù)據(jù)來自google的論文FAIlure Trends in a Large Disk Drive Population，文中詳細探討了通用設備磁盤的故障情況。它給出的磁盤年度故障率的統(tǒng)計圖，如下所示：

img

可以看到，前三個月會超過2%的磁盤損壞率，到第二年這個數(shù)字會上升到8%左右。

你可能會說，這個數(shù)字也不是很高啊。

但你要知道，對金融行業(yè)的關鍵應用系統(tǒng)來說，通常是要求具備5個9的可靠性（99.999%），也就是說，一年中系統(tǒng)的服務中斷時間不能超過5.26分鐘（365*24*60*（1-99.999%） ≈ 5.26 ）。

而且，不只是金融行業(yè)，隨著人們對互聯(lián)網(wǎng)的依賴，越來越多的系統(tǒng)都會有這樣高的可靠性要求。

根據(jù)這兩個數(shù)字，我們可以設想一下，如果你所在的公司有四、五個關鍵業(yè)務系統(tǒng)，十幾臺 DB服務器，磁盤數(shù)量一定會超過100個吧？那么我們保守估計，按照損壞率2%來算，一年中就會碰到2次磁盤損壞的情況，要達到5個9的可靠性你就只有5.26分鐘，能處理完一次磁盤故障嗎？這幾乎是做不到的，可能你剛沖到機房，時間就用完了。

我猜你會建議用RAID（獨立冗余磁盤陣列）來提高磁盤的可靠性。這確實是一個辦法，但也會帶來性能上的損耗和存儲空間上的損失。分布式 DB的副本機制可以比RAID更好地平衡可靠性、性能和空間利用率三者的關系。副本機制就是將一份數(shù)據(jù)同時存儲在多個機器上，形成多個物理副本。

回到 DB的話題上，可靠性還要更復雜一點，包括兩個度量指標，恢復時間目標（Recovery Time Objective, RTO）和恢復點目標（Recovery Point Objective, RPO）。RTO是指故障恢復所花費的時間，可以等同于可靠性；RPO則是指恢復服務后丟失數(shù)據(jù)的數(shù)量。

DB存儲著重要數(shù)據(jù)，而金融行業(yè)的 DB更是關系到客戶資產(chǎn)安全，不能容忍任何數(shù)據(jù)丟失。所以， DB高可靠意味著RPO等于0，RTO小于5分鐘。

傳統(tǒng)上，銀行通過兩種方法配合來實現(xiàn)這個目標。

第一種還是采購小型機和大型機，因為它們的穩(wěn)定性優(yōu)于x86服務器。

第二種是引入專業(yè)存儲方案，例如EMC的Symmetrix遠程鏡像軟件（Symmetrix Remote Data Facility, SRDF）。DB采用主備模式，在高端共享存儲上保存 DB文件和日志，使 DB近似于無狀態(tài)化。主庫一旦出現(xiàn)問題，備庫啟動并加載共享存儲的文件，繼續(xù)提供服務。這樣就可以做到RPO為零，RTO也比較小。

但是，這套方案依賴專用的軟硬件，不僅價格昂貴，而且技術體系封閉。在去IOE（IBM小型機、Oracle DB和EMC存儲設備）的大背景下，我們必須另辟蹊徑。分布式 DB則是一個很好的備選方案，它憑借節(jié)點之間的互為備份、自動切換的機制，降低了x86服務器的單點故障對系統(tǒng)整體的影響，提供了高可靠性保障。

令人興奮的是，這種單點故障處理機制甚至可以延展到機房層面，通過遠距離跨機房部署。如此一來，即使在單機房整體失效的情況下，系統(tǒng)仍然能夠正常運行， DB永不宕機。

3.0定義，分布式 DB是服務于寫多讀少、低延時、海量并發(fā)OLTP場景的，高可靠的關系型 DB。

3.4 海量存儲

雖然單體 DB依靠外置存儲設備可以擴展存儲能力，但這種方式本質(zhì)上不是 DB的能力。現(xiàn)在，借助分布式的橫向擴展架構，通過物理機的本地磁盤就可以獲得強大的存儲能力，這讓海量存儲成為分布式 DB的標配。

最后，我們終于得到一個4.0終極版本的定義，分布式 DB是服務于寫多讀少、低延時、海量并發(fā)OLTP場景的，具備海量數(shù)據(jù)存儲能力和高可靠性的關系型 DB。

4 內(nèi)部視角：內(nèi)部構成

具有相同的外在特性和功效，未必就是同樣的事物。

“日心說”反駁“地心說”要用到34個圓周解釋天體運動軌跡；而100多年后，開普勒只用7個橢圓就達到同樣效果，徹底摧毀“地心說”。從哥白尼到開普勒，效果近似，簡潔程度大不一樣，這背后代表的是巨大科學進步。

因此，講完外部特性，還要從內(nèi)部視角觀察。

為應對海量存儲和海量并發(fā)，很多解決方案在效果上跟V4定義相似。但它們向用戶暴露了太多的內(nèi)部復雜性。用戶約束太多、使用過程太復雜、不夠內(nèi)聚的方案，不能稱為成熟產(chǎn)品。同時，業(yè)界的主流觀點并不認為它們是分布式 DB。

來看分類：

4.1 客戶端組件 + 單體 DB

通過獨立的邏輯層建立數(shù)據(jù)分片和路由規(guī)則，實現(xiàn)單體 DB的初步管理，使應用能夠對接多個單體 DB，實現(xiàn)并發(fā)、存儲能力的擴展。其作為應用系統(tǒng)的一部分，對業(yè)務侵入比較深。

這種客戶端組件的典型產(chǎn)品是Sharding-JDBC。

4.2 代理中間件 + 單體 DB

以獨立中間件的方式，管理數(shù)據(jù)規(guī)則和路由規(guī)則，以獨立進程存在，與業(yè)務應用層和單體 DB相隔離，減少了對應用的影響。隨著代理中間件的發(fā)展，還會衍生出部分分布式事務處理能力。

這種中間件的典型產(chǎn)品是MyCat。

img

4.3 單元化架構 + 單體 DB

單元化架構是對業(yè)務應用系統(tǒng)的徹底重構，應用系統(tǒng)被拆分成若干實例，配置獨立的單體 DB，讓每個實例管理一定范圍的數(shù)據(jù)。例如對于銀行貸款系統(tǒng)，可以為每個支行搭建獨立的應用實例，管理支行各自的用戶，當出現(xiàn)跨支行業(yè)務時，由應用層代碼通過分布式事務組件保證事務的ACID特性。

根據(jù)不同的分布式事務模型，應用系統(tǒng)要配合改造，復雜性也相應增加。例如TCC模型下，應用必須能夠提供冪等操作。

在分布式 DB出現(xiàn)前，一些頭部互聯(lián)網(wǎng)公司使用過這種架構風格，該方案的應用系統(tǒng)的改造量最大，實施難度也最高。

共同的特點是單體DB仍能夠被應用系統(tǒng)感知到。相反，分布式 DB則是將技術細節(jié)收斂到產(chǎn)品內(nèi)部，以一個整體面對業(yè)務應用。

5 亞馬遜的Aurora

和這里說的分布式DB有明顯差別，了解Aurora或同類產(chǎn)品嗎？和本文分布式DB差異在哪？為啥會有這種差異？

為啥說Aurora不是分布式DB？Aurora存算分離，使亞馬遜云存儲服務更高效、易使用。算是NewSQL中比較成功的了。

特點

Aurora是提出一種新的單體架構以減少網(wǎng)絡IO和同步阻塞，邏輯上可以看做一個龐大的單體 DB，用分布式來支持容錯和高吞吐量。：

Aurora分片的方式是將 DB的總容量劃分為固定大小的數(shù)據(jù)段，在每一段內(nèi)存儲數(shù)據(jù)，每一個段是一組機器（六個），個人覺得算支持分片
寫多讀少、低延時這就是Aurora所重點的做的事情，通過log is database和支持異步來實現(xiàn)
海量存儲可靠堆機器（當然這些機器肯定是有一個控制中心來管理的，論文中沒有提）
高可靠則是靠每一個數(shù)據(jù)段把數(shù)據(jù)冗余到三個可用區(qū)的六臺機器
而且它同樣也是關系型DB

但Aurora特點是Share storage，計算節(jié)點垂直擴展，存儲節(jié)點水平擴展，寫入性能收單機資源的影響。

投票機制

aurora也用到了，6個副本，半數(shù)以上就確認寫入成功。但無分片，不能多寫，肯定不算分布式。

不能多寫（重點！），適用場景有很大區(qū)別，所以這是個重要標準。但因為Aurora是基于共享存儲，所以說它是分布式也不是沒道理。定標準只是為讓學習思路清晰。

實際場景Aurora和分布式存儲的應用的差別

Aurora還是關系型 DB，而分布式存儲系統(tǒng)范圍較廣，比如HBase這樣的分布式鍵值系統(tǒng)。兩者在功能上有很大差異。

AWS aurora，阿里polarDB，騰訊CynosDB，華為的Taurus等產(chǎn)品都是類似架構：計算存儲分離。所有計算節(jié)點都訪問存儲節(jié)點上的同一份數(shù)據(jù)，也可以說是分布式架構。這架構的局限是寫入不能橫向擴展，對很多小規(guī)模應用夠了，所以不影響它取得商業(yè)成功。

阿里的PolarDB是分布式DB？它采用哪種方案？

PolarDB和Aurora架構類似，存算分離，計算節(jié)點垂直擴展，存儲節(jié)點水平擴展。代表其寫入能力有上限，但因簡化了日志存儲和其他一些優(yōu)化，單點能力比普通MySQL強很多。

6 總結

逐層遞進，勾勒出分布式 DB的六個外部特性：寫多讀少、低延時、海量并發(fā)、海量存儲、高可靠性、關系型 DB。

也存在一些與分布式 DB能力近似解決方案，它們不足之處是都需要對應用系統(tǒng)進行一定的改造，對應用的侵入程度更深；其優(yōu)勢則在于可以最大程度利用單體 DB的穩(wěn)定可靠，畢竟這些特性已經(jīng)歷經(jīng)無數(shù)次的考驗。

分布式DB的名稱做一些延伸。

“分布式 DB”在字面上可以分解為“分布式”和“ DB”兩部分，代表了它是跨學科的產(chǎn)物，它的理論基礎來自兩個領域。這同時也呼應了產(chǎn)品發(fā)展的兩條不同路徑，一些產(chǎn)品是從分布式存儲系統(tǒng)出發(fā)，進而增加關系型 DB的能力；另外一些產(chǎn)品是從單體 DB出發(fā)，增加分布式技術元素。而隨著分布式 DB的走向工業(yè)應用，在外部需求的驅動下，這兩種發(fā)展思路又呈現(xiàn)出進一步融合的趨勢。

7 FAQ

① 寫多讀少不應加入分布式DB的定義？

分布式DB服務寫多讀少應用，我覺得不管寫多讀多都可應用分布式，關鍵是單體承擔不了這么多請求了（不論讀寫），所以高并發(fā)就夠了，寫多讀少不應加入分布式DB的定義？

強調(diào)寫多讀少，是因為：

寫操作的負載只能是單體DB的主節(jié)點，無法轉移
而讀操作，如對一致性要求不高，可轉移到備節(jié)點，甚至在某些條件下還能保證一致性。就是說單體DB可通過一主多備解決讀負載大問題，而無需引入分布式DB

云dbms在分布式基礎上，更關注計算存儲分離后可獨立擴展，甚至動態(tài)擴縮容，self-driven搞起來，更好賣了。這也引發(fā)不少問題，aurora類 DB提出log is database思想，降低寫壓力，snowflake通過建立中間分布式換存層，降低網(wǎng)絡瓶頸等。

② 分布式DB V.S 分庫分表

分布式關系型DB，感覺就是把客戶端或中間件的方案直接作為DB服務端的特性組件，把分庫分表做得更自動化？

最大區(qū)別在于：

分布式DB使用體驗很接近關系型DB，無需應用進行額外控制，大大降低業(yè)務代碼開發(fā)難度
而分庫分表方案在分布式事務和跨節(jié)點查詢等方面，支持的都不好

③ MyCat這種怎么說？

隨分布式DB發(fā)展，MyCat這類中間件市場會越來越小。當然，它的使用場景也可能轉向對異構DB支持，就像Presto。

④ 都說互聯(lián)網(wǎng)應用數(shù)據(jù)請求“讀多寫少”

所以有了一主多從讀寫分離、全量數(shù)據(jù)緩存等解決“讀”問題的擴容手段。如果說的是同一個指標，是否意味著分布式DB不適合互聯(lián)網(wǎng)應用？

互聯(lián)網(wǎng)確實可通過一主多滿足“讀多寫少”，但前提是對讀對一致性要求低。而金融場景，很多讀操作依然無法在備庫運行，就是一致性不滿足要求。所以，對互聯(lián)網(wǎng)也不能一概而論，還是區(qū)分場景。

⑤ 交易場景下，交易代碼配合分布式 DB而做出的交易補償或者數(shù)據(jù)回放等

如需要交易代碼配合做出補償和回放，這很可能意味著它不是分布式DB。分布式DB成熟前，確有不少應用代碼配合單體 DB。這類應用代碼也會被抽離出來形成獨立框架，如阿里SOFA。

⑥ Newsql落地如何？

如北京銀行和光大銀行都上線TiDB，Oceanbase也在南京銀行落地。

⑦ BigTable算特殊的（代理中間件 + 單體 DB（分布式文件系統(tǒng)））嗎？

畢竟靠Chubby作為一個中間層，不過數(shù)據(jù)的獲取是直接與文件系統(tǒng)中交互完成。

BigTable是分布式KV系統(tǒng)，不屬于分布式DB。因為這里所說的分布式DB是分布式架構實現(xiàn)的關系型DB。當然它底層依賴一個分布式文件系統(tǒng)，所以看上去也分兩層，但職能和DB差別很大，建議關注PGXC風格分布式DB。

⑧ 基于OLAP使用場景的分布式關系型DB產(chǎn)品

最典型的MPP架構DB，如Greenplum和華為的GaussDB 200，內(nèi)核都使用PostgreSQL。還有Vertica。OLAP不再強調(diào)事務支持，如果弱化對數(shù)據(jù)更新要求，很多大數(shù)據(jù)生態(tài)的產(chǎn)品都可納入，如Clickhouse，Hive on spark，甚至Kylin都算是廣義OLAP分布式DB。