怎樣打造一款分布式數據庫

怎樣打造一款分布式數據庫，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

關系型數據庫在過去數十年的數據庫領域一直占據著絕對主導的地位，它所帶來的穩定性、安全性和易用性，成為了構建現代化系統的基石。隨著的互聯網高速發展，構架于單機系統的數據庫已無法滿足越來越高的并發請求和越來越大的數據存儲需求，因此，分布式數據庫被愈加廣泛的采用。

一直以來，數據庫領域均由西方的科技公司和社區所主導。而今，越來越多的國產數據庫解決方案以分布式為支點，逐漸在此領域有所建樹。Apache ShardingSphere 是其中的一個分布式數據庫解決方案，也是目前 Apache 軟件基金會中唯一的數據庫中間件。

全面兼容面向傳統關系型數據庫的 SQL 和事務，并且對分布式的天然友好，是分布式數據庫解決方案的設計目標。它的核心功能主要集中在以下幾點：

• 分布式存儲: 數據存儲不受單機磁盤容量限制，可通過增加數據服務器的數量提升存儲能力；

• 計算存儲分離: 計算節點無狀態，可通過水平擴展增加算力。存儲節點和計算節點能夠分層優化；

• 分布式事務: 高性能、完全支持本地事務 ACID 原義的分布式事務處理引擎；

• 彈性伸縮：可以隨時隨地的在不影響現有應用的情況下，動態對數據存儲節點擴容和縮容；

• 多數據副本：自動將數據以強一致、高性能的方式復制至跨機房的多個副本，以保證數據的絕對安全；

• HTAP：采用同一套產品混合處理 OLTP 的事務型操作和 OLAP 的分析型操作。

分布式數據庫的實現方案可以劃分為進取型和穩定型。進取型實現方案是指開發全新架構的 NewSQL。這類產品以追求更高性能換取穩定性的缺失和運維經驗的不足；穩定型的實現方案是指在現有數據庫的基礎上提供增量能力的中間件。這類產品則以犧牲部分性能以保證數據庫的穩定性和運維經驗的復用。

Apache ShardingSphere 是一套開源的分布式數據庫中間件解決方案組成的生態圈，它由 Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar（計劃中）這 3 款相互獨立的產品組成。它們均提供標準化的數據分片、分布式事務和分布式治理等功能，可適用于如 Java 同構、異構語言、云原生等各種多樣化的應用場景。隨著 Apache ShardingSphere 在查詢優化器和分布式事務引擎的不斷探索，它已漸漸地打破了實現方案的產品邊界，向集進取型和穩定型于一身的平臺級解決方案演進。

定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務。它使用客戶端直連數據庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全兼容 JDBC 和各種 ORM 框架。

定位為透明化的數據庫代理端，提供封裝了數據庫二進制協議的服務端版本，用于完成對異構語言的支持。目前已提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL 和 PostgreSQL 協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat 等) 操作數據，對 DBA 更加友好。

定位為 Kubernetes 的云原生數據庫代理，以 Sidecar 的形式代理所有對數據庫的訪問。通過無中心、零侵入的方案提供與數據庫交互的的嚙合層，即 Database Mesh，又可稱數據庫網格。

Sharding-JDBC 采用無中心化架構，適用于 Java 開發的高性能的輕量級 OLTP 應用；Sharding-Proxy 提供靜態入口以及異構語言的支持，適用于 OLAP 應用以及對分片數據庫進行管理和運維的場景。

每種架構方案都有其各自的優缺點，下面表格對比了各種架構模型的在不同場景下的優劣：

Apache ShardingSphere 是多接入端共同組成的生態圈。通過混合使用 Sharding-JDBC 和 Sharding-Proxy，并采用同一配置中心統一配置分片策略，能夠靈活的搭建適用于各種場景的應用系統，使得架構師更加自由的調整適合與當前業務的最佳系統架構。

Apache ShardingSphere 采用 Share Nothing 架構，它的 JDBC 和 Proxy 接入端均采用無狀態設計。作為計算節點，Apache ShardingSphere 負責對獲取的數據進行最終的計算匯總。由于本身并不存儲數據，因此 Apache ShardingSphere 可以將計算下推至數據節點，以充分利用數據庫自身的計算能力。Apache ShardingSphere 可以通過增加部署節點數量來增加計算能力；增加數據庫節點數量來增加存儲能力。

數據分片、分布式事務、彈性伸縮和分布式治理是 Apache ShardingSphere 目前階段的 4 個最核心功能。

分而治之是 Apache ShardingSphere 用于處理海量數據的方案。Apache ShardingSphere 通過數據分片方案，使數據庫具備分布式存儲能力。

它可以將 SQL 根據用戶預置的分片算法自動路由至相應的數據節點，以達到操作多個數據庫的目的。用戶可以像使用單機數據庫一樣使用被 Apache ShardingSphere 所管理的多個數據庫。目前支持 MySQL、PostgreSQL、Oracle、SQLServer 以及任何支持 SQL92 標準和 JDBC 標準協議的數據庫。數據分片的內核流程見下圖：

主要流程如下：

1. 通過解析數據庫協議包或 JDBC 驅動獲取用戶輸入的 SQL 和參數；

2. 根據詞法分析器和語法分析器將 SQL 解析為 AST（抽象語法樹），并提取分片所需信息；

3. 根據用戶預置算法匹配分片鍵，并計算路由路徑；

4. 將 SQL 改寫為分布式可執行 SQL；

5. 向各數據節點并行發送 SQL，執行引擎負責連接池與內存資源的平衡；

6. 根據 AST 執行流式或全量內存結果集歸并計算；

7. 封裝數據庫協議包或 JDBC 結果集，并返回至客戶端。

事務是數據庫系統的最核心功能。分布式的不確定和事務的復雜性，決定了分布式事務領域無法出現放之四海而皆準的方案。

面對百花齊放的現狀，Apache ShardingSphere 提供高度開放的方案，采用標準接口統一整合開發者自主選擇的第三方分布式事務框架，以滿足各種場景的應用需求。除此之外，Apache ShardingSphere 還提供了全新的分布式事務解決方案 JDTX，來彌補現有方案的缺失。

Apache ShardingSphere 為本地事務、兩階段事務和柔性事務提供了統一的適配接口，并對接了大量的現有第三方的成熟解決方案。通過標準接口，開發者可以輕松的將其他整合方案融入到 Apache ShardingSphere 平臺中。

然而，融合大量第三方解決方案，卻不能覆蓋所有分布式事務需求分支。各種解決方案均有各自的適合及不適合場景。各解決方案間是互斥的，無法將它們的優點疊加使用。針對于當前最常見 2PC（兩階段提交）和柔性事務，分別存在著以下的優勢和不足：

• 兩階段提交：基于 XA 協議實現的兩階段分布式事務對業務侵入很小。它最大的優勢是對使用方透明，開發者可以像本地事務一樣使用基于 XA 協議的分布式事務。XA 協議能夠嚴格保障事務 ACID 特性，但這也是一把雙刃劍。事務執行在過程中需要將所需資源全部鎖定，它更加適用于執行時間確定的短事務。對于長事務來說，整個事務進行期間對資源的獨占，將導致對熱點數據依賴的業務系統并發性能衰退明顯。因此，在高并發的性能至上場景中，基于 XA 協議兩階段提交類型的分布式事務并不是最佳選擇。

• 柔性事務：如果將實現了 ACID 的事務要素的事務稱為剛性事務的話，那么基于 BASE 事務要素的事務則稱為柔性事務。BASE 是基本可用、柔性狀態和最終一致性這 3 個要素的縮寫。在 ACID 事務中對一致性和隔離性的要求很高，在事務執行過程中，必須將所有的資源占用。柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性和隔離性的要求，只要求當整個事務最終結束的時候，數據是一致的。而在事務執行期間，任何讀取操作得到的數據都有可能被改變。這種弱一致性的設計可以用來換取系統吞吐量的提升。

基于 ACID 的兩階段事務和基于 BASE 的最終一致性事務都不是銀彈，可通過下表詳細對比它們之間的區別。

缺乏并發度保障的兩階段事務不能稱之為完善的分布式事務解決方案；而缺乏對 ACID 原義支持的柔性事務都甚至不能稱之為數據庫事務，它更適合服務層的事務處理。

放眼當前，實難找到無需權衡即可放之四海而皆準的分布式事務解決方案。

JDTX 是京東數科自研的分布式事務中間件，尚未開源。它的設計目標是強一致（支持 ACID 的事務原義）、高性能（不低于本地事務性能）、1PC（完全摒棄兩階段提交和兩階段鎖）的完全分布式事務中間件，目前可用于關系型數據庫。它采用完全開放 SPI 的設計方式，提供與 NoSQL 對接的可能，未來能夠將多元異構數據維持在同一事務中。

JDTX 通過完全自研的事務處理引擎，將 SQL 操作的事務中數據轉化為 KV（鍵值對），并在其基礎上實現了 MVCC（多版本快照）的事務可見性引擎，以及與數據庫設計理念類似的 WAL（預寫日志系統）存儲引擎。可以通過下面的架構圖來了解一下 JDTX 的構成：

它的設計特點是將在事務中的數據（稱之為活躍數據）和不在事務中的數據（稱之為落盤數據）分離。活躍數據在落盤至 WAL 之后，再以 KV 的形態保存至 MVCC 內存引擎中。落盤數據則是通過異步刷盤的方式，將 WAL 中的 REDO 日志，以流量可控的方式同步至最終的存儲介質中（如：關系型數據庫）。事務內存查詢引擎負責使用 SQL 從 KV 格式的活躍數據中檢索到相關數據，與落盤數據合并，并根據事務隔離級別獲取符合當前事務可見的數據版本。

JDTX 以全新的架構重新詮釋了數據庫的事務模型，主要亮點有：

1、內化分布式事務為本地事務

JDTX 的 MVCC 引擎是一個集中式緩存。它能夠將兩階段提交內化至一階段提交，以維持單一節點中數據的原子性和一致性，即將分布式事務的范疇縮減到本地事務的范疇。JDTX 通過保證所有對事務數據的訪問都通過 MVCC 引擎的活躍數據 + 最終數據端的落盤數據的合并的方式，以保證事務數據的原子性和一致性。

2、無損的事務隔離機制

以 MVCC 的方式實現事務隔離性。目前完整的支持 4 種標準隔離級別中的讀已提交和可重復讀，已經可以滿足絕大部分需求。

3、高性能

采用將活躍數據異步刷盤至存儲介質的方式，極大地提高了數據寫入的性能上限。它的性能瓶頸從數據庫寫入耗時轉移到了落盤至 WAL 和 MVCC 引擎的耗時。

與數據庫的 WAL 系統類似，JDTX 的 WAL 也采用順序日志追加的方式，因此可以簡單的理解為 JDTX 的 WAL 耗時 = 數據庫系統的 WAL 耗時。而 MVCC 引擎則采用 KV 數據結構，其寫入耗時小于維護 BTree 索引的數據庫。因此，JDTX 的數據更新性能的上限甚至可以高于不開啟事務。

4、高可用

WAL 和 MVCC 引擎均可以通過主備 + 分片的方式維持高可用和水平擴展的能力。在 MVCC 引擎完全不可用的情況下，可通過恢復模式將 WAL 中的數據同步至數據庫，以保證數據的完整性。

5、跨多元數據庫事務

將事務活躍數據和落盤數據分離的設計方案，使其落盤數據存儲端無任何限制。由于事務活躍數據通過異步的落盤執行器存儲至后端存儲介質，因此后端是否為同構數據庫，其實并無影響。使用 JDTX 能夠保證跨多元存儲端（如：MySQL、PostgreSQL，甚至是 MongoDB、Redis 等 NoSQL）的分布式事務維持在同一事務語義之中。

通過 Apache ShardingSphere 提供的分布式事務統一適配接口，可以將 JDTX 像其他第三方分布式事務解決方案一樣輕松地融入 Apache ShardingSphere 生態，將數據分片與分布式事務無縫結合，使它們具備組成分布式數據庫基礎設施的能力。架設在產品最前端的 Apache ShardingSphere 用于 SQL 解析、數據庫協議和數據分片；位于中層的 JDTX 用于通過 KV 和 MVCC 的方式處理事務活躍數據；最底層的數據庫則僅作為最終的數據存儲端。下圖是 ShardingSphere + JDTX 的架構圖。

可以說，JDTX 的存在，使得 Apache ShardingSphere 打破了穩定型的數據庫中間件的定位，在保持穩定的同時，逐步向進取型 NewSQL 發展。

與無狀態的服務化應用不同，數據節點中均持有不可丟失的重要用戶數據。當數據節點的容量不足以承擔快速增長的業務時，數據節點的擴容則在所難免。根據用戶預置的分片策略不同，擴容的策略也會隨之不同。

彈性伸縮可以讓被 Apache ShardingSphere 所管理的數據庫在不停止對外服務的情況下進行擴容和縮容。彈性伸縮分為彈性遷移和范圍擴容兩個組件，目前它們均在孵化中。

數據遷移是面向用戶定制分片策略的標準擴縮容方案。在遷移過程中，需要準備兩套數據節點。原數據節點在繼續提供服務的同時，將數據以存量和增量的方式，分別寫入新數據節點。整個遷移過程無需停止對外服務，可以平順的過渡新舊數據節點。Apache ShardingSphere 還將提供工作流界面，讓遷移過程完全自主可控。彈性遷移的架構圖如下：

具體流程如下：

1. 通過配置中心修改數據分片配置，以觸發遷移流程。

2. 記錄當前遷移數據開啟前的位點之后，開啟歷史遷移作業，分批遷移全量數據。

3. 開啟 Binlog 訂閱作業，遷移位點之后的增量數據。

4. 根據采樣率設置比對數據。

5. 設置原數據源只讀，確保實時數據遷移完成。

6. 將應用連接切換至新數據源。

7. 舊數據源下線。

遷移時長根據數據量的大小可能是幾分鐘至幾周不等。遷移過程中可以隨時回退或重新遷移。整個遷移流程完全自主可控，降低遷移過程中的風險；并且通過自動化工具完全屏蔽人工操作，避免繁瑣的操作帶來的巨大工作量。

如果彈性遷移稱之為硬伸縮的話，那么范圍擴容則稱之為軟伸縮。Apache ShardingSphere 的范圍擴容不涉及內核改造，也無需遷移數據，它只需通過優化范圍分片策略，即可達到自動擴（縮）容的目標。使用范圍擴容，用戶無需感知分片策略和分片鍵等分庫分表方案中必要概念，讓 Apache ShardingSphere 更加接近一體化的分布式數據庫。

使用范圍擴容的用戶，只需向 Apache ShardingSphere 提供數據庫資源池。容量巡檢器會在表容量到達閾值時，從資源池中依次尋找下一個數據節點，并在新數據節點創建新表之后，修改分片策略的范圍元數據。當資源池中沒有新數據節點后，Apache ShardingSphere 會按照同樣的順序，在已經創建過表的數據庫中增加新表。當表數據大量刪除時，之前的數據節點的數據將不再緊湊，垃圾回收器會定時壓縮表范圍，以釋放更多的碎片空間。范圍擴容的結構如下：

Apache ShardingSphere 為不同的應用場景，提供了更加靈活的彈性伸縮策略。目前仍在孵化中的兩個彈性伸縮相關的項目，也力爭盡快提供試用版本。

治理模塊的設計目標是為了更好管理和使用分布式數據庫。

與所有的分布式系統的設計理念一脈相承，分而治之同樣是分布式數據庫的指導方針。數據庫治理能力的存在，能夠讓管理成本不隨著數據庫實例數目的增長而提升。

Apache ShardingSphere 使用配置中心來管理配置，可以在配置修改后的極短時間內傳播到所有的接入端實例。配置中心采用開放的 SPI 方式，能夠充分利用配置中心自身的能力，如配置多版本變更等。

Apache ShardingSphere 使用注冊中心管理接入端實例和數據庫實例的運行狀態。注冊中心同樣采用配置中心的開放 SPI 方式。部分注冊中心的實現可以涵蓋配置中心的能力，因此用戶可以疊加使用注冊中心和配置中心的能力。

Apache ShardingSphere 提供了數據庫實例禁用和接入端熔斷的能力，分別用于處理數據庫實例不可用和接入端被大流量沖擊的場景。

Apache ShardingSphere 目前正在孵化高可用的 SPI，讓用戶能夠復用數據庫自身提供的高可用方案。目前正在對接 MySQL 的 MGR 高可用方案。Apache ShardingSphere 可以通過自動探知 MGR 的選舉變化并快速傳播至所有的應用實例。

大量數據庫和接入端實例，使得 DBA 和運維人員無法迅速感知當前系統的狀況。Apache ShardingSphere 通過對 OpenTracing 協議的實現，將監控數據發送至實現其協議的第三方 APM 系統中；除此之外，Apache ShardingSphere 還提供了 Apache SkyWalking 的自動探針，可以讓使用它作為可觀察性產品的用戶直接觀測到 Apache ShardingSphere 的性能、調用鏈關系以及系統的整體拓撲圖。

得益于 Apache ShardingSphere 對 SQL 靈活的處理能力和對數據庫協議的高度兼容性，數據相關的治理能力也被很方便的加入到了產品生態中。

Apache ShardingSphere 可以讓用戶在無需修改代碼的情況下，自動將指定的數據列加密后存儲至數據庫，并在應用程序獲取數據時解密，以保證數據的安全。當數據庫的數據被不慎泄露時，敏感數據信息由于被完全加密，從而不會造成更大的安全隱患。

Apache ShardingSphere 可以在系統進行全鏈路壓測時，自動將用戶標記的數據路由至影子庫（表）。影子庫（表）壓測功能可以讓線上壓測成為常態，用戶無需在關心壓測數據的清理。此項功能也正在高速的孵化中。

如您所見，Apache ShardingSphere 正處于高速發展的軌道中，越來越多與“分庫分表”這條曾經主線并無強關聯的功能被加入其中。但這些產品功能卻并不突兀，它們反而能助力 Apache ShardingSphere 成為更加多元化的分布式數據庫解決方案。Apache ShardingSphere 未來的線路主要會集中在以下幾點。

越來越多的零散功能需要進一步梳理。Apache ShardingSphere 現有的架構還不足以完全吸收如此廣泛的產品功能。彈性化的功能可插拔平臺是 Apache ShardingSphere 未來架構的調整方向。

可插拔平臺會將 Apache ShardingSphere 從技術和功能兩方面完全拆開。Apache ShardingSphere 的全景圖如下所示：

Apache ShardingSphere 會根據技術架構橫向分為 4 層，分別是接入層、SQL 解析層、內核處理層和存儲訪問層；并且將功能以可插拔的形態融入至 4 層架構中。

Apache ShardingSphere 對數據庫類型的支持將完全開放，除了關系型數據庫，NoSQL 也會完全開放支持，數據庫方言互不影響，完全解耦。在功能方面，Apache ShardingSphere 采用疊加式架構模型，使各個功能可以靈活的組合使用。每個功能模塊只需關注自身的核心功能，由 Apache ShardingSphere 架構負責功能的疊加組合使用。即使沒有任何功能，Apache ShardingSphere 也可以作為一個空白的接入端直接啟動，為開發者的定制化開發提供腳手架以及 SQL 解析等基礎設施。融入 Apache ShardingSphere 生態的數據庫，將直接獲得平臺提供的所有基礎能力；在 Apache ShardingSphere 平臺上開發的功能，也將直接獲得已接入平臺的數據庫類型的全部支持。數據庫類型和功能類型將以相乘的方式排列組合，基礎設施 + 樂高的組合，將為 Apache ShardingSphere 提供各種想象和提升的空間。

目前 Apache ShardingSphere 只是將 SQL 通過正確的路由和改寫，分發至相應的數據庫以操作數據。計算下發能夠充分利用的數據庫的查詢引擎，但無法有效的支持復雜關聯查詢和子查詢。基于關系代數實現的 SQL on KV 查詢引擎隨著 JDTX 的開發日臻成熟，將其積累的經驗反哺于 SQL 查詢引擎，能夠讓 Apache ShardingSphere 更好的支持子查詢和跨庫關聯查詢等復雜查詢。

分布式數據庫所需要的多數據副本能力目前的 Apache ShardingSphere 還未具備。未來 Apache ShardingSphere 將提供基于 Raft 的多副本寫入能力。

上文中提到的 Sharding-Sidecar 接入端，是 Apache ShardingSphere 未來的第三個接入端形態，旨在更好的與 Kubernetes 配合，打造云原生數據庫。

Database Mesh 的關注重點在于如何將分布式的數據訪問應用與數據庫有機串聯起來，它更加關注的是交互，是將雜亂無章的應用與數據庫之間的交互有效的梳理。使用 Database Mesh，訪問數據庫的應用和數據庫終將形成一個巨大的網格體系，應用和數據庫只需在網格體系中對號入座即可，它們都是被嚙合層所治理的對象。

支持更多的數據庫類型之后，Apache ShardingSphere 會將工作重點放在多元異構的數據庫類型的統一查詢引擎之上。除此之外，Apache ShardingSphere 還將配合 JDTX，將更加多元的數據存儲介質納入到同一事務中。

Apache ShardingSphere 在 2016 年 1 月 17 日在 GitHub 平臺首次開源，開源項目的初始名稱是 Sharding-JDBC。在 2018 年 11 月 10 日，ShardingSphere 改名并正式進入 Apache 軟件基金會的孵化器。

在開源至今走過的 4 年里程中，Apache ShardingSphere 的架構模型在不斷的演進的同時，整體產品的功能范圍也在急速地擴張。它從開源之初的分庫分表 Java 開發框架，逐漸演化為分布式數據庫解決方案。

隨著 Apache ShardingSphere 的生態圈的擴張，由少數開發者掌控項目的狀態早已被打破。目前的 Apache ShardingSphere 有近百名貢獻者，以及近 20 名核心提交者，他們共同打造著這個遵循著 Apache Way 的社區。Apache ShardingSphere 是一個標準的 Apache 軟件基金會開源項目，并不受某一商業公司或某幾位核心開發者掌控。

目前有超過 100 家公司明確的聲明他們在使用 Apache ShardingSphere，讀者可以從官方網站找到采用公司的用戶墻。

隨著社區的成熟，Apache ShardingSphere 的成長也越來越迅速。我們誠邀感興趣的開發者一同參與到 Apache ShardingSphere 社區中，完善不斷擴大的生態。

關于怎樣打造一款分布式數據庫問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。