第2章　從集中式到分布式數據庫

話說天下大勢，分久必合，合久必分。周末七國分爭，并入于秦。及秦滅之后，楚、漢分爭，又并入于漢。漢朝自高祖斬白蛇而起義，一統天下，后來光武中興，傳至獻帝，遂分為三國。

天下大勢的分分合合，正如走路使用兩條腿，左右交替進行，才能行穩致遠。只有左，或者只有右，都只能步履蹣跚。

20世紀70～80年代，集中式數據庫的代表Oracle、Db2問世，之后不斷推陳出新，在商業銀行獨領風騷數十年。但隨著商業銀行業務模式的不斷創新，產生了大量數據，特別是交易吞吐量開始有了上千倍的增長。在這種情況下，現有的集中式數據庫受制于硬件的發展，遇到了性能和容量瓶頸，如何提升數據庫的處理能力就擺在了所有商業銀行的面前。

在現有的計算機體系結構和硬件沒有獲得實質性突破（如量子計算的商用）之前，聰明的人類通過對架構的改進，推出了分布式數據庫，極大地增強了系統的整體性能和容量，滿足了當前飛速發展的業務需要！

集中式和分布式就如數據庫的兩條腿，交替邁進，有力地推動了數據庫領域的發展，本章將詳細講解數據庫從集中式到分布式的演進過程。

隨著商業銀行數字化業務的加速發展，以及摩爾定律的失效，集中式數據庫由于采用單機部署而遇到了性能和容量瓶頸，這不僅意味著業務發展受到影響，而且某種程度上也會影響現有系統的穩定性和可用性。

早在2010年，一些大型的互聯網公司就遇到這類制約業務發展的技術問題。最原始的方案就是將一個MySQL數據庫拆分為多個庫。為了應用程序訪問拆分后的多個數據庫，阿里巴巴開發了TDDL（Taobao Distributed Data Layer）框架，解決分庫分表對應用的透明化以及異構數據庫之間的數據復制；2016年，當當網又發起了Sharding-JDBC項目，這些方案都是通過包裝JDBC來屏蔽MySQL分庫分表的邏輯，實現業務系統如同使用單機數據庫一樣方便。

后來，JDBC封裝框架逐漸演變到中間件。在TDDL的基礎上，阿里巴巴逐漸發展出來了DRDS；當當網發起的Sharding-JDBC轉移到京東數科。京東數科的數據庫技術人員之后又孵化出來了Sharding-Proxy，目前已經作為Apache軟件基金會的頂級項目，名稱為Apache ShardingSphere。這些方案都是以一個虛擬的MySQL Server提供更透明和無侵入的客戶端接入服務。

另一方面，隨著Google的Spanner、阿里巴巴的OceanBase和PolarDB、AWS的Aurora、PingCAP的TiDB、Cockroachlabs的CockroachDB等商業或開源技術的不斷發展，分布式數據庫開始大規模興起。這些技術試圖通過一個直接的分布式數據庫來解決上述問題，而不僅是包裝JDBC或者中間件來解決。

以上種種對于企業來說，都是通過采用類似Apache ShardingSphere這種分布式的數據庫中間件或者CockroachDB這種分布式數據庫作為整體解決方案，增強數據庫的吞吐能力，保證高可用和實時強一致性的同時，實現線性的水平擴展能力，在一定規模上提升企業信息系統的數據管理上限。

本章以某商業銀行電商管家系統講起，介紹該系統演化中每一個階段的技術特點、解決的問題、適用的場景等；最后進入本章的主題，將以中信銀行自研的金融級分布式數據庫——GoldenDB為例，深入講解其原理、應用開發和運維最佳實踐。