節(jié)前寫過一篇關(guān)于分布式數(shù)據(jù)庫的文章，當(dāng)時有幾個朋友和我討論集中式數(shù)據(jù)庫和分布式數(shù)據(jù)庫如何選擇的問題。實際上，數(shù)據(jù)庫產(chǎn)品都不是萬能的，對于不同的應(yīng)用場景，不同的用戶群體，其對數(shù)據(jù)庫的選擇有所不同。對于一些用戶或者一些應(yīng)用場景來說，可能選擇分布式數(shù)據(jù)庫是必然的選擇，另外一些用戶或者應(yīng)用場景，選擇集中式數(shù)據(jù)庫更簡單一些。

總體來說，集中式數(shù)據(jù)庫因為相對簡單，因此可能適用的場景更廣泛一些，特別是對于中小型非關(guān)鍵性系統(tǒng)或者沒有能力運行于維護(hù)大型分布式數(shù)據(jù)庫系統(tǒng)的用戶來說，選擇集中式數(shù)據(jù)庫可能更符合企業(yè)的需求。

實際上使用集中式數(shù)據(jù)庫的客戶也需要很多分布式數(shù)據(jù)庫具有的特性，比如高可用、多副本、故障自動隔離、橫向擴(kuò)展等。

很多用戶都怕集中式數(shù)據(jù)庫的單機總體容量可能受限，實際上對于絕大多數(shù)系統(tǒng)來說，單機容量達(dá)到極限還是很困難的。無論是內(nèi)存，CPU，IO，網(wǎng)絡(luò)、存儲容量，現(xiàn)在的上限都相當(dāng)高，對于一般的系統(tǒng)來說還是比較難達(dá)到極限的。

雖然如此，集中式數(shù)據(jù)庫支持某種意義上的橫向擴(kuò)展還是很有必要的。比如ORACLE 的RAC，雖然不能像分布式數(shù)據(jù)庫一樣橫向擴(kuò)展到幾十上百個節(jié)點，RAC的橫向擴(kuò)展能力還是會讓人感到比較放心。對于國產(chǎn)集中式關(guān)系型數(shù)據(jù)庫來說，強一致性讀寫分離是很好的橫向擴(kuò)展方式，其實現(xiàn)方式?jīng)]有Oracle RAC那么難，又能夠解決大量的讀操作消耗過多系統(tǒng)資源的問題。通過一個較好的方案實現(xiàn)強一致性讀寫分離，是國產(chǎn)集中式數(shù)據(jù)庫在同質(zhì)化競爭中脫穎而出的一個途徑。

可能有些朋友會說了，現(xiàn)在的國產(chǎn)數(shù)據(jù)庫，開源數(shù)據(jù)庫，基本上都有類似的功能，這個有什么難的。實際上目前開源、國產(chǎn)數(shù)據(jù)庫的集群計算都是外掛的，不是從數(shù)據(jù)庫的底層設(shè)計開始的，僅僅是集群計算框架與原有RDBMS內(nèi)核的整合。

要想把這個問題說清楚，首先我們需要分析一下客戶為什么需要找個功能。有些時候客戶需要強一致性的讀寫分離并不是為了橫向擴(kuò)展，而是用一種最簡單的方式實現(xiàn)應(yīng)用系統(tǒng)的高可用。

數(shù)據(jù)庫的無數(shù)據(jù)丟失強一致性同步一直是保證數(shù)據(jù)庫高可用的一種客戶的強需求，雖然大部分用戶可以接受部分的數(shù)據(jù)丟失，只要當(dāng)主系統(tǒng)故障的時候，能夠快速恢復(fù)業(yè)務(wù)就可以達(dá)到他們的最基本的要求。不過正是因為故障切換是有損的，所以在真正做切換的時候還是會有些猶豫。因為每次切換后，都有一些臟數(shù)據(jù)要處理，對于運維部門，業(yè)務(wù)部門，開發(fā)商來說，都是留下了一些尾巴。如果切換后能夠?qū)崿F(xiàn)0數(shù)據(jù)丟失，不需要做收尾的工作，那么當(dāng)主系統(tǒng)故障時，就會十分堅決的進(jìn)行故障切換了。

強一致性同步的另外一個好處是，我們的MIS類的系統(tǒng)中，讀寫比例高達(dá)8:2甚至9:1，在應(yīng)用的角度上講，把一些讀操作都轉(zhuǎn)移到只讀副本上去，可以大大減少主實例的負(fù)擔(dān)，也可以減少主實例故障的幾率。如果主備實例的數(shù)據(jù)不是隨時都是完全一致的，那么我們的應(yīng)用需要做相應(yīng)的修改，確保某些只讀操作是可以在只讀副本上運行，有些只讀操作需要強一致性，必須在主實例上運行。不過如果主從數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)隨時都能確保強一致，那么在一個集群環(huán)境中寫應(yīng)用的難度就大大降低了。

除了強一致性的讀寫分離，客戶的另外一個重要需求就是透明應(yīng)用故障切換，這個詞Oracle簡稱TAF，屬于RAC故障切換的一種早期方式，雖然十多年前這種切換方式就已經(jīng)被更為強大的快速連接故障切換（FCF）所替代，不過目前國內(nèi)的大多數(shù)應(yīng)用軟件還在使用TAF。TAF的好處是當(dāng)數(shù)據(jù)庫實例故障時，應(yīng)用可以自動切換。

Oracle 12.1后支持的GDS服務(wù)就可以在一個集群計算環(huán)境中支持讀寫分離、負(fù)載均衡與故障切換，我們的國產(chǎn)數(shù)據(jù)庫廠商可以認(rèn)真學(xué)習(xí)一下其功能與實現(xiàn)方式。

Oracle GDS可以構(gòu)建一個統(tǒng)一而又復(fù)雜強大的統(tǒng)一計算環(huán)境，讓RAC\ADG\OGG等復(fù)制技術(shù)與計算框架有效地整合成一個整體。

我們需要數(shù)據(jù)庫集群計算環(huán)境的強一致性，強一致性讀寫分離的實現(xiàn)方式主要有以下幾種：

• 第一種模式：多實例共享存儲+緩沖區(qū)融合的讀寫分離：多個讀寫分離的數(shù)據(jù)庫實例共用一套存儲數(shù)據(jù)，只有主實例支持讀寫，其他實例均為只讀。對于未寫盤的臟塊，直接從主實例的緩沖區(qū)中獲得。這種實現(xiàn)方式比ORACLE RAC的多主模式實現(xiàn)起來要簡單一些；
• 第二種模式：多實例共享存儲+WAL APPLY：和第一種模式類似，采用一主多從模式，主實例可讀寫，其他實例只讀。不同的是，多實例之間是完全獨立的，不通過緩沖區(qū)融合來保證讀寫一致性，而是通過在備用實例上重演WAL數(shù)據(jù)來確保讀寫一致性。這種模式比第一種模式的優(yōu)點是主從實例之間完全是獨立的，互相的影響不大，只要底層存儲支撐得住，從節(jié)點的數(shù)量多一點也問題不大。缺點是如果主實例存在大量的寫操作，那么從實例的重演可能會產(chǎn)生一定的延時。Polardb-PG就是采用這種模式的一個例子；

• 第三種模式是多實例存儲復(fù)制+WAL APPLY：為了防止底層存儲的IO性能達(dá)到極限，從底層實現(xiàn)存儲的同步/半同步自動復(fù)制，確保多個存儲副本之間的數(shù)據(jù)一致性。不同的實例可以使用獨立的副本，或者某幾個有限的實例共享一個獨立的副本。其他的實現(xiàn)方式和第二種模式類似，這是第二種模式的變種方案。亞馬遜的AURORA DB CLUSTER就是這種模式的典型案例；

• 第四種模式是多實例非共享存儲0數(shù)據(jù)丟失復(fù)制：主從實例是完全獨立的數(shù)據(jù)庫，在存儲底層確保WAL數(shù)據(jù)自動實現(xiàn)無損復(fù)制，確保已經(jīng)提交的事務(wù)的WAL文件能夠復(fù)制到從庫。從庫通過日志重演確保與主庫的同步或者半同步。

實際上，以目前的數(shù)據(jù)庫與分布式數(shù)據(jù)庫技術(shù)，實現(xiàn)上述的四種模式，在技術(shù)上并沒有不可逾越的難關(guān)，最關(guān)鍵的是需要從數(shù)據(jù)庫SQL引擎、存儲引擎、緩沖區(qū)管理、DB WRITER、WAL WRITER等核心組件上到操作系統(tǒng)、存儲系統(tǒng)、網(wǎng)絡(luò)實現(xiàn)全棧貫通的設(shè)計和優(yōu)化，使之成為一體化的數(shù)據(jù)庫設(shè)計，而不是把一堆組件做簡單的集成。這種一體化的設(shè)計與實現(xiàn)，才能夠從整體上實現(xiàn)最優(yōu)處理，自動處置各種異常，并自動進(jìn)行相關(guān)的容錯處理，從而確保數(shù)據(jù)庫提供的強一致性讀寫、故障切換、故障數(shù)據(jù)修復(fù)等都是能夠根據(jù)數(shù)據(jù)庫底層模塊自動完成的，而不是需要運維人員或者應(yīng)用開發(fā)商去做相關(guān)的處理的。甚至今后在SQL執(zhí)行算子方面實現(xiàn)下推，實現(xiàn)某些計算場景跨數(shù)據(jù)庫實例的并行計算。

這種計算框架可以解決一些當(dāng)前集中式數(shù)據(jù)庫中比較麻煩的問題。比如大型數(shù)據(jù)庫表分析時產(chǎn)生的大量IO導(dǎo)致的系統(tǒng)性能問題。在這種計算框架下，可以按照下面的方式實現(xiàn)集群計算。

當(dāng)表分析任務(wù)發(fā)起后，主庫分解分布式計算的任務(wù)，通過消息隊列分發(fā)任務(wù)給各多個從庫，由從庫完成實際的計算任務(wù)，再把結(jié)果發(fā)送給主庫，由主庫統(tǒng)一入庫。再通過復(fù)制技術(shù)分發(fā)到各個從庫。

如果是十多年前，當(dāng)硬件處理能力、分布式復(fù)制技術(shù)等還沒有發(fā)展到今天的時候，集中式數(shù)據(jù)庫的設(shè)計可能不會向這個方向去考慮，不過隨著這些年軟硬件與分布式計算框架的高速發(fā)展，我們的集中式數(shù)據(jù)庫的架構(gòu)設(shè)計是不是也可以脫離開已經(jīng)使用了幾十年的老方案，嘗試一些適合現(xiàn)代軟硬件技術(shù)的新的方案呢？

實際上Oracle GDS也不是原生態(tài)的集群計算框架，是集成了ADG、OGG、ONS、FAN、ADG FAR SYNC等技術(shù)基礎(chǔ)上逐步發(fā)展起來的集成計算框架。不過從GDS我們也可以看出，集中式數(shù)據(jù)庫完全可以從單打獨斗模式過渡到了集群計算的新模式了。

實際上，集群計算模式在開源社區(qū)的發(fā)展也很迅速，MYSQL MGR就是一種典型的集群計算架構(gòu)。只是目前的大多數(shù)集群計算架構(gòu)大多數(shù)是以數(shù)據(jù)庫與服務(wù)組件集成的方式組建的，并不是基于數(shù)據(jù)庫原生態(tài)設(shè)計的，沒有形成硬件、操作系統(tǒng)、數(shù)據(jù)庫內(nèi)核、服務(wù)網(wǎng)關(guān)的一體化設(shè)計，因此在應(yīng)用上還需要大量的工程化的實施工作，運行時也還需要對整個集群進(jìn)行監(jiān)控和調(diào)整，無法像一個數(shù)據(jù)庫一樣一體化部署和一體化運行。

實際上我們完全可以從數(shù)據(jù)庫底層開始一體化設(shè)計一個支持集群計算框架的集中式數(shù)據(jù)庫系統(tǒng)，將現(xiàn)有集群計算的工程化工作變得十分簡化，這種基于集群計算架構(gòu)的集中式數(shù)據(jù)庫在技術(shù)實現(xiàn)上會比分布式數(shù)據(jù)庫簡單不少，而其使用效果肯定也是相當(dāng)不錯的。