為內容面很大，我的整體思路是從一些概念的邊界入手來進行相關策略的推導，過程中會側重展開一些落地的案例和設計思想，我將通過如下4個部分的內容來進行闡述。

一、關于架構思路和一些概念邊界

1.為什么需要數據庫分布式架構？

首先需要有一個整體的認識，為此有一個靈魂拷問：為什么需要數據庫分布式架構？答案確實是千人千面，為此我整理了一個比較粗略的圖來說明我的觀點。

早期的數據庫架構模式主要是單機模式。單機模式雖然也能滿足我們早期一些業務需求，但是隨著數據規模的擴大以及業務的快速增長，對單機數據庫體系有了更高要求，從而延伸出以下幾個發展方向：

1）通過更高級配置、擴大容量等方式將原本的單機數據庫變得更大更強，在這種情況下，數據庫會變成一個“超人”，如上圖所示的“超人”。

2）將業務分為多個部分完成，這種模式發展到后期可能會產生多個分支，如果容量越來越大，需求的復雜度會越來越高，可能涉及到集群模式管理，如上圖所示的“三個工人”和”兩個超人”。

3）集群模式可能會延伸出另一種模式，當原本的單機模式難以擴展時，我們可以將原本的高配單機增加至兩個或者多個，然后通過業務拆分來完成，這種情況可能會導致一種尷尬局面，容量足夠的情況下部分配置存在上限，例如達到一定程度后數據庫會變得“臃腫”。為解決這一問題，人工難以承載的業務可以基于代理層來實現，如上圖所示的“六個工人+代理人”。

4）上述第三種模式再進行延伸，可能出現另一種模式，將數據存儲與數據管理分離，即將數據存儲與數據計算分離，這一過程需要相關的調度管理進行銜接和協作，如上圖右側所示。

以上內容通過一個小案例講述了為什么需要數據庫分布式架構，可能初聽“數據庫分布式架構”有些拗口，下面將對分布式數據庫與數據庫分布式架構這兩個概念進行區分。

2.概念邊界

這些年來分布式數據庫、云原生數據庫的概念都很火熱，同時分布式架構、微服務架構等在行業內也有大量的落地場景和最佳實踐。我們通常所說的分布式數據庫和數據庫分布式架構還是有一定的區別的，但是又存在一定的關聯，就好比如下的包含關系一樣，是一種層級遞進的關系。

對上面的圖我提煉出幾個要點：

• 分布式數據庫是分布式架構的重要一環，但不是完全強依賴，也就意味著業務層的架構設計好壞能夠直接影響整體的架構質量。
• 數據庫分布式架構的發展空間相比于分布式數據庫更大，它更貼近于業務，分布式只是數據庫分布式架構的一種演進策略。
• 云原生數據庫是分布式數據庫的一種演進形式，相對來說更為垂直。

如上圖左側圖形所示，做分布式涉及到的整體成本相對較高，并且在硬件、軟件、開發測試等方面存在差異。

目前分布式數據庫的版圖大體分為三類：基于分片模式的數據庫集群，基于NewSQL的分布式數據庫和云原生數據庫三大類，在不同的分類中都有相應的典型代表和頭部玩家，他們都有各自擅長的業務場景和領域，目前來看基于分片模式的數據庫集群的發展相對成熟，而基于NewSQL和云原生數據庫的發展這些年增長很快，目前已然是一種新的數據庫架構演進趨勢。說到架構，必然需要考慮架構的考量維度。

3.通用架構能力

通常會按照如下的三個維度來進行整體的架構考量：彈性擴展，高可用和高性能，這三個維度能夠大體衡量架構設計的目標是否滿足預期。

1）彈性擴展。原本的單機可能不夠用，我們可以通過彈性擴展方式將原來的水平擴展演進為彈性擴展。

2）高可用。通過架構能力可以實現中間件節點高可用、數據節點高可用等整體的高可用。

3）高性能。架構能力可以在讀寫性能方面做到更高能力支撐。

至此，我們從一些概念和架構考量維度上有了一個整體的認識，那么前面說到架構是需要持續演進的，那么到底有什么架構策略，是否可以大一統呢？我打算從單機和數據兩個維度來推導架構的策略。

二、從單機和數據維度推導架構策略

架構的演進通常是依據需求和業務的發展動態適配的，如果單機配置能夠滿足容量，性能等資源需求，在開發設計周期和系統復雜度層面都是一種比較理想的平衡狀態，也是比較建議的，但是很多業務發展趨勢不是線性的，而是指數級的變化和增長，這種情況下就需要在先期的架構設計中進行預防性架構設計，也就是我們在設計初期就不能從潛意識中偷懶，等到業務發展的速度和后端的改造能力不匹配的時候，問題就會接踵而至，而很多在前期沒有考慮到的問題在基于分布式設計時，無論是開發周期和系統復雜度都會難以接受。

1.單機維度推導架構演進策略

單機模式下的分布式架構可以拆分為三個維度：系統配置、數據庫配置和數據庫相關服務管理。

1）系統配置

系統配置包括CPU、內存等，相對來說是一個固化的模式，對其進行擴展的難度較低，其成本也已經隨著硬件的發展大幅度降低，簡單來說，如果在成本可控范圍內，花錢升級硬件就能解決。

2）數據庫配置

數據庫配置包括單庫容量、單表容量、連接數和吞吐量等，其中單庫容量擴展存在一定瓶頸。綜合來看，對數據庫配置做擴展會有些難度，但是這個時候有些復雜度，不是單純升級硬件就能夠解決的，比如我曾經管理過一張表，容量有1T，對于單機來說是需要相當謹慎的，這里的難度等級約為中等。

3）服務管理

服務管理包括負載管理、高可用管理、事務管理、運維管理等。在事務管理的復雜度方面，單機模式比分布式好一些。在管理模式上，單機模式使用了All In One模式，算是集中式管理，而分布式管理需要大量的自動化運維支撐。分布式管理在負載管理和高可用管理方面相比于單機管理有較大提升。在混合負載方面，原本的單機模式是整個服務的整體覆蓋，但在分布式架構體系內要考慮整體負載能力的提升，不能因為單一節點的短板導致整個集群被拖垮，整體的難度相對較高。

2.數據維度推導架構演進策略

首先將數據分為以下三個維度：

1）流水型數據

流水型數據是無狀態的，多筆業務之間沒有關聯，每次業務過來的時候都會產生新的單據，比如交易流水，支付流水，只要能插入新單據就能完成業務，特點是后面的數據不依賴前面的數據，所有的數據按時間流水進入數據庫。

2）配置型數據

配置型數據即我們所說的配置中心字典，數據字典配置等。此類型數據數據量較小，而且結構簡單，一般為靜態數據，變化頻率很低。 

3）狀態性數據

狀態型數據是有狀態的，多筆業務之間依賴于有狀態的數據，而且要保證數據的準確性，例如賬戶余額，做充值時必須要拿到原來的余額才能支付成功，因此狀態型數據整體的維護最復雜，是我們現在做分布式事務管理的核心部分。

基于以上數據類型分類我們可以延伸出三類表：字典表、日志表和狀態表。

在架構設計上和演進方面，配置型和流水型數據的擴展方案相對比較豐富，通常不需要事務管理，所以擴展和性能方面表現都很出色，方案落地性更強，難度最大的是狀態型數據，因為它存在數據的關聯和依賴，所以需要事務管理，在擴展性和性能方面的解決方案不夠完美，需要做一定的取舍，如事務降維，或把數據強一致性的需求降為最終一致性等。

下面將對這三類表進行對比架構演進策略的解讀。

① 數據量

字典表的數據量最小，日志表數據量極大，狀態表的數據量大小與業務規模相關。

② 數據依賴

字典表基本不存在事務依賴，即使有，也只存在于極少數的配置中；日志表沒有事務依賴，所以改造日志表的切入點比較好找；狀態表整體有事務依賴。

③ 業務特點

字典表整體上為讀多寫少的模式；日志表的著重點為大批量密集型讀寫，整體為讀少寫多的模式；狀態表整體為讀多寫多的模式。

④ 架構策略

• 架構1.0策略

我們通常基于讀寫分離的模式對字典表做擴展改進。對于日志表，我們需要考慮提前做拆庫、拆表，我們將這種模式稱為周期表。對于狀態表，我們可以通過讀寫分離的模式對讀這部分的流量做緩解，但并不能從根本上解決問題。

• 架構2.0策略

對于字典表可以采用全局的分庫分表方式。對日志表主要使用業務路由和數據庫中間件。狀態表相較于前兩者更為復雜，其中一種方式是分庫分表，另一種方式是基于分庫分表模式做事務降維或整體的過程中直接做事務降維。事務降維包括兩種方式，一種是在整個的過程中根據業務的特點不啟用事務，另一種是在設計中將事務的維度或顆粒度降到最低，基于最小化的分片維度執行操作。

⑤ 系統優化策略

字典表的優化比較清晰，我們可以通過緩存模式進行優化，該方法可解決大部分問題。日志表在寫入過程中，實時延遲不會很高，我們可以基于隊列采用異步方式提升整個系統的吞吐量。狀態表主要對讀這部分的狀態因數據做緩存。在系統優化策略維度，字典表和日志表比較容易進行優化，狀態表的加工改造策略是重難點，而且整個過程中也無法徹底解決問題，對設計的整體要求也較高。

⑥ 建設目標

字典表適用于建設配置中心，日志表適用于建設賬單存儲平臺，狀態表適用于建設數據中臺。

三、架構演進與案例分析 

這部分我將架構的演進歷程分為1.0、2.0、3.0三個階段，便于下文講述，該劃分方式并無嚴格的優劣之分。

架構1.0階段的主要策略為垂直拆分、拆庫拆表以及讀寫分離。

架構2.0階段的主要策略為基于數據庫中間件和業務路由的分布式方案。

架構3.0階段的主要策略為基于云關系型數據庫和分布式關系型數據庫的方式。

在整個架構以及架構策略的演進過程中，整體模式與前文中提到的模式相似。單機模式通過業務拆分或者2.0階段的業務路由和數據庫中間件策略滿足業務需求。在3.0階段，通過存算分離以及調度層統籌滿足業務需求。以下對每個階段進行詳細解讀。

1.架構1.0階段和案例

在這一階段，我們采用了拆庫拆表的方式將商業數據庫遷移到MySQL中。原本我們可能處于單機模式，在整個單機模式下，我們通過拆庫拆表方式將業務拆分到兩個相對獨立的服務器上，再實現日志數據的異步寫入。對于狀態型數據，我們可以做讀寫分離的改進。

在1.0階段，我們通過拆分隔離將業務進行拆分，包括兩種拆分方式：

1）將大的狀態型業務拆分為兩部分，一部分為全局型業務，另一部分為特定某個去向的業務。例如游戲公司有20款游戲，我們將這些游戲的公共屬性數據拆分出來在平臺層重組，再針對不同游戲的獨特屬性數據進行擴展。

2）在單機模式下將日志型數據和狀態型數據進行拆分。日志型數據拆分難度較低，通過數據庫中間件即可實現。拆分日志型數據的過程中，面對大量讀的要求可以通過一主多從的方式進行讀寫分離的改進。

在這一階段，對數據量極大的表進行變更很困難，簡單來說，單機數據庫中對于流水型數據存在明顯的瓶頸，比如一張表每天產生20G的日志，那么單機容量的規格假設是300G，就僅僅能夠保存2周左右的數據，而數據清理通常需要業務側寫相應的邏輯進行定時處理，在數據庫負載和查詢性能方面都有一定的隱患。為改善這一問題，我們提出了周期表的概念，根據時間將表分為日、周、月、年和幾年五個維度，日志數據都可以按照這五個維度進行拆分。將日志數據根據周期表進行拆分的好處是便于對數據進行清理，整個清理過程中維護代價也較低。我們為了落實數據清理工作也做了一些狀況類化，例如DBA實現表的自動擴展與自動清理。對表進行清理并非對現有表直接清理，而是設置一個期限，例如一個月，超過期限后將表放入回收站中，再對表內容進行操作，操作過后將表放置到另外的庫中，超過一定期限后逐步清理。這整個過程中，如果有一些數據需要恢復，我們可以快速重置。現在我們已經接入了四五百個周期表，形成了自循環的管理模式，而對于公司整體業務來說，幾乎很難看看到一些數據量恐怖的表，因為這些都通過這種設計模式基本杜絕了。

2.架構2.0演進和案例

1）消息業務路由改造

架構2.0階段首先做業務路由的改造。早期我們做消息業務的改造，例如打開APP后的消息推送，整體的吞吐量較大。在早期的業務中，對于消息存儲的數據統計要求較高，我們希望能夠盡快將消息推送抵達用戶并獲得反饋，使得整個業務運營形成閉環。

如上圖右側所示，是數據庫側的I/O使用情況，在進行I/O優化的過程中，一個主節點難以承載負荷，所以我們將查詢需求擴展到了從節點做了讀寫分離，后期發現仍不能滿足要求，統計查詢還是非常卡頓，I/O使用率還是被打滿。我們進行了列式存儲擴展，將統計查詢遷移過去后提高了查詢效率，算是解決了查詢瓶頸問題，原服務的I/O使用率一下子降低了60%以上，再后來通過業務路由將一個節點動態擴展為三個節點，如上圖左側所示，性能又有了明顯改善，提升了20%左右，整個過程是一個循序漸進的優化過程。 

2）數據庫中間件

第二類是基于數據庫中間件的模式，數據庫中間件方式需要考慮數據的重分布、數據的可用性和同城異地容災等。

基于這種架構模式，我們也做了一些特色化的服務，主要有4點：

• 中間件負載均衡

數據庫集群架構模式通過Consul服務把原來的三層結構改成了兩層，實現了中間件層的負載均衡。

• 配置化建表

對于線上數據庫集群創建表的需求，我們通過配置實現數據表的定制化創建。比如我們需要我們創建一張表時，只需要在配置表里寫一條配置信息，之后我們會通過服務掃描配置變化，如果發生變化，就會在線上創建相關的表，保證業務的連續性，這個過程看似簡單，實際上對于集群的結構設計要求是很高的。

• 數據流轉

對于集群的數據流轉，是數據分分合合的難點，我們通過流轉程序來實現，如DataX來進行數據聚合，為此我們構建了一個中間層來統一流轉，后續的思路是直接將賬單存儲改造為NewSQL數據庫，直接提供實時數據交付。

• 只讀查詢

一些線上數據的復雜查詢也可以通過只讀中間件去做，把它掛載到一個只讀的中間件節點上可以平滑實現在線的數據查詢，后續打算通過雙集群模式（中間件+NewSQL集群）來提供平滑的讀寫需求。如果這4點的力道不足，那么中間件架構還存在如下的兩個典型優勢可以補充，分別是數據重分布和分布式集群組的存儲模式。

① 數據重分布

第一個優勢數據重分布，因為中間件架構優缺點并存，我們在實踐過程中經歷了很多考驗，對于中間件架構來說，個人覺得它的一大特色就是拓撲結構的可擴展性。比如硬件服務器在多年后需要過保替換，逐個服務器替換還是會產生系統抖動，如果有幾十個節點，這種替換其實會存在一定的風險，基于中間件架構可以快速實現拓撲結構擴展，如上圖所示，可以補充一套從庫節點，然后將中間件收縮，再將3層拓撲切換為兩層，對于幾十上百個節點的快速切換，這是一種很優雅的模式，整個切換過程在3.5秒左右，當業務服務具備重連機制，集群內部其實已經發生了質的變化。

② 優勢分布式集群組/通用存儲方案設計

第二個優勢分布式集群組/通用存儲方案設計，比如我們所說的數據庫分布式架構整體需要去滿足業務需求，發現有很多數據表結構都是相似的，在這種情況下，我們就可以實現動態、靈活的存儲管理模式。

主要分為兩個維度：第一，通用存儲意味著我們原來的一套集群不夠，我們可以再補一套集群實現，這樣就是集群組的模式。在這個層面上，我們就把集群下沉一層，在上層進行配置化的管理，在上層有一個全局配置；第二，我們通過全局配置可以快速靈活地生成一些定制化的表結構，比如有的業務對于數據的存儲需求是varchar(32)，而有的是varchar(256)或者bigint，這些都可以在集群組中動態配置，從而適配不同的模板，通過這種靈活的配置管理的方式實現整個集群組數據的存儲管理。

3.架構3.0演進和技術分析

我們經常聽到云關系型數據庫和分布式關系型數據庫等概念。

個人經過整理發現數據庫的整個演進過程中有許多故事。Google很早就開始在內部孵化Spanner，2011年左右發布論文，論文發布后形成了兩個分支，一個分支對原本的模式不滿，另一分支從原本的模式中受到啟發對其進行了改進。以上兩種分支延伸出兩大派別，一種是基于Aurora模式，并基于此思想產生了Aurora數據庫，例如騰訊的CynosDB和阿里云的PolarDB等。另一種是受Spanner論文思想影響下產生基于另一體系的TiDB等數據庫。

從整體上看，兩大派別較大的差異在于Aurora等數據庫與MySQL沒有太大差異，整體采用了存算分離的架構，而另一派別的數據庫是以NewSQL全新的設計體系，兼容MySQL協議的形式出現，兩者屬于不同的體系，在數據庫分布式架構策略方面也有不同的實現，從早期的讀寫分離模式到周期表、中間件，后續還會有新型中間件等。

1）數據庫分布式架構策略對比

其實云原生數據庫從某種概念上來說是彎道超車，云原生數據庫中以Aurora為典型代表的數據庫，其底層設計本質為讀寫分離模式，但核心技術是分布式共享存儲，它是從讀寫分離的模式經歷了大跨越的更新。

① 云原生數據庫-Aurora

我們簡單來看一下具有代表性的Aurora數據庫，是AWS在MySQL的基礎上進行了魔改，因為AWS對Spanner的事務處理能力不滿意，提出日志即數據庫，并重新設計讀寫分離集群，延伸出Aurora數據庫，其整體為6副本，底層基于S3，整體采用讀寫分離模式。

② CynosDB，PolarDB

CynosDB和Aurora有一些差異，但其整體還是存儲計算分離的結構，基于Raft,將redo下推至存儲管理。PolarDB基于RDMA，沒有將redo下推至存儲，其本質還是基于存儲計算分離的模式。

③ TiDB體系結構

我們TiDB的調研時間較早，在早期也是在測試環境中沉淀了許久，然后逐步從日志型數據庫改造開始，逐步引入更多的業務范圍。

4.數據庫分布式架構演進小結

通過總結我們在分布式架構方面的實踐，我把整個分布式架構分兩個維度，一個維度是從水平擴展的能力考量，另一個維度是從吞吐量這個方面考慮。如果原來的單機處于起點，垂直拆分可能有較大提升。

我們在2018年時已經大量使用讀寫分離模式，當然讀寫分離模式對于很多敏感的業務不是那么嚴謹，但在很多數據不是那么敏感或者延遲不那么敏感的情況下，是一個相對簡單的架構改進。

在演進過程中我們少走了一些彎路。我們對很多賬單表的數據提前做了布局和拆分，把它改造成周期表模式，周期表模式改造好后，我們目前為止很少見到數據量非常大的表，基于此，我們自然的引入了中間件的分庫分表方案。對于中間件集群的方案，我們后續有兩種模式，一種是做業務拆分，另一種是套入原來的通用存儲方案，通過配置化的方式實現集群組的管理。

這個階段后會有一個分界點，也是關于數據庫最后一個非常核心的點——事務管理。事務管理方面，一種方式是復雜的管理模式，另一種是最小顆粒度的事務管理。之后的新型的中間件還有NewSQL體系，我們都進行了嘗試，并在2021年落地了技術棧。

在此，我補充一些數據來對不同的架構策略做一些對比。

從整個分布式體系來看，各方面有利有弊，我們要去理性看待一項技術，不一定NewSQL體系就是最好的。為保證觀點的嚴謹，我通過雷達圖從以下幾個方面進行了對標準版實例、數據庫中間件和NewSQL三者進行了評估。

• 事務管理

基于單機模式長周期的驗證，標準實例在事務管理方面最有優勢。中間件在事務管理方面存在瓶頸。NewSQL集群的思路模型依托的是另一種體系，需要時間周期的驗證以及業務場景的匹配，所以其介于兩者之間。

• 驗證周期

單機模式有長時間的驗證周期。

• 遷移升級

三者在遷移方面都有相對成熟的體系。

• 高可用

相較于其他二者，NewSQL在高可用方面具有明顯優勢。

• 擴縮容

在擴縮容方面單機模式相對受限。NewSQL在擴縮容方面最有優勢，能夠實現某種程度的彈性擴縮容。

• 性能

中間件的方案對于一些性能極度敏感，在有良好設計的情況下，其整體性能更有優勢。

綜上所述，應該根據不同的場景選擇適合的方案，切勿一刀切。

四、技術展望和小結

1.數據庫架構演進趨勢分析

1）數據庫生態之國產化

從整個數據庫架構的演進過程來看，現在的數據庫生態變得越來越多元化，同時也存在一定的差異化和風險，在此我想多提一下國產化數據庫，因為這是生態中不可或缺的。

目前國內的數據庫國產化程度還是比較高的，如果從近些年來研發技術和數據庫的緊密結合來看，很明顯研發方向是在降低對于數據庫的重邏輯依賴，轉而通過分布式技術架構來滿足性能和擴展性等強烈需求，而互聯網作為開源技術的試驗田，提供了大量的業務場景使得開源軟件能夠不斷成熟迭代。在功能實現上，國產數據庫也更為貼合國內用戶的使用需求和體驗。從這個層面來看，國產化數據庫通常都具有分布式的成長基因。

但是，在行業中也在短時間內產生了大量的數據庫定制化產品，這些都是在核心組件和底層服務之外的偏個性化定制，使得用戶在林林總總的國產化數據庫中容易迷茫，另外國產數據庫如果僅僅是為了對標和其他商業數據庫的兼容度，個人感覺會受到過多束縛和限制，因為過多的泛應用化會讓數據庫技術的基礎沉淀不夠扎實，而過度迎合用戶使用體驗而在設計理念上妥協，會讓數據庫技術難以聚焦，限制更大的發揮潛力。

2）做得更少 vs 做得更多

在數據庫分布式架構的改造中，做得更少對我來說是顛覆認知的收獲。我們早期做分布式架構性能提升時希望做得更多，支撐更高的OPS，提供更高更強的性能，但我們做架構改造的過程中發現有些情況卻恰恰相反，基于業務的視角去做一些架構優化反而能夠取得更好的效果，最后發現原來支撐了幾十萬的OPS,經過優化幾萬OPS就足夠了，從這個層面來說，數據庫分布式架構的發展空間很大。

3）分布式共享存儲

云原生數據庫有共享存儲的影子，例如Aurora是基于讀寫分離模式，它之所以在分布式方向實現彎道超車，是因為其核心部分是分布式共享存儲技術，在云原生數據庫中，原來看起來“土味的”共享存儲模式其實玩出了新的花樣。

4）HTAP需要理性

原本單一的OLTP和OLAP業務，在開發和管理中存在諸多不便，而HTAP在一定程度上能夠有效的結合兩者的優勢，從而提供更為統一高效的數據服務，我想這應該是近些年來HTAP大火的原因，在這個基礎上我建議要警示數據膨脹的問題，ALL IN的問題帶來的隱患會隨著時間的增長而變得更加棘手。

所以對于HTAP方案，我并不十分認可All In One 的模式，或者說存在一些擔心，我們需要理性看待HTAP方案。

2.基于機器學習的數據庫監控異常預測研究

近些年來AIOps還是很火的，數據庫也會搭上這輛便車。我前段時間進行了一些機器學習相關的研究，將成百上千的服務器通過機器學習的方式做相關監控數據的預測，如上圖我們基于回歸模型和時序模型進行了預測，整體上基本實現了對某些指標的周期性預測。

那么問題來了，機器學習異常預測與分布式架構有何關系呢？根據我的理解，原本數據庫的負載預測是基于單機模式，而我們在考量集群分布式架構時，需要從更全局的集群角度看待，定位短板，和單機模式是有很大的差別。從這個層面來說，如果我們有一些分布式體系的異常預測模型，我們就可以在此基礎上做更多工作。

?楊建榮?

競技世界 數據庫專家

dbaplus社群聯合發起人，騰訊云TVP，Oracle ACE，《Oracle DBA工作筆記》和《MySQL DBA工作筆記》作者；

現就職于競技世界，擅長數據管理、數據遷移、性能優化，目前專注于開源技術、運維自動化和性能優化，堅持寫技術博客，已堅持2400多天。?