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

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

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

很多用戶都怕集中式數據庫的單機總體容量可能受限，實際上對于絕大多數系統來說，單機容量達到極限還是很困難的。無論是內存，CPU，IO，網絡、存儲容量，現在的上限都相當高，對于一般的系統來說還是比較難達到極限的。

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

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

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

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

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

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

Oracle 12.1后支持的GDS服務就可以在一個集群計算環境中支持讀寫分離、負載均衡與故障切換，我們的國產數據庫廠商可以認真學習一下其功能與實現方式。

Oracle GDS可以構建一個統一而又復雜強大的統一計算環境，讓RAC\ADG\OGG等復制技術與計算框架有效地整合成一個整體。

我們需要數據庫集群計算環境的強一致性，強一致性讀寫分離的實現方式主要有以下幾種：

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

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

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

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

這種計算框架可以解決一些當前集中式數據庫中比較麻煩的問題。比如大型數據庫表分析時產生的大量IO導致的系統性能問題。在這種計算框架下，可以按照下面的方式實現集群計算。

當表分析任務發起后，主庫分解分布式計算的任務，通過消息隊列分發任務給各多個從庫，由從庫完成實際的計算任務，再把結果發送給主庫，由主庫統一入庫。再通過復制技術分發到各個從庫。

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

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

實際上，集群計算模式在開源社區的發展也很迅速，MYSQL MGR就是一種典型的集群計算架構。只是目前的大多數集群計算架構大多數是以數據庫與服務組件集成的方式組建的，并不是基于數據庫原生態設計的，沒有形成硬件、操作系統、數據庫內核、服務網關的一體化設計，因此在應用上還需要大量的工程化的實施工作，運行時也還需要對整個集群進行監控和調整，無法像一個數據庫一樣一體化部署和一體化運行。

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