ShardingSphere 看這一篇就夠了

一、什麼是shardingSphere

​ Apache ShardingSphere 是一套開源的分佈式數據庫中間件解決方案組成的生態圈，它由 JDBC、Proxy 和 Sidecar（規劃中）這 3 款相互獨立，卻又可以混合部署配合使用的產品組成。 它們均提供標準化的數據分片、分佈式事務和數據庫治理功能，可適用於如 Java 同構、異構語言、雲原生等各類多樣化的應用場景。

​ Apache ShardingSphere 定位爲關係型數據庫中間件，旨在充分合理地在分佈式的場景下利用關係型數據庫的計算和存儲能力，而並不是實現一個全新的關係型數據庫。 它經過關注不變，進而抓住事物本質。關係型數據庫當今依然佔有巨大市場，是各個公司核心業務的基石，將來也難於撼動，咱們目前階段更加關注在原有基礎上的增量，而非顛覆。

​ Apache ShardingSphere 5.x 版本開始致力於可插拔架構，項目的功能組件可以靈活的以可插拔的方式進行擴展。 目前，數據分片、讀寫分離、多數據副本、數據加密、影子庫壓測等功能，以及 MySQL、PostgreSQL、SQLServer、Oracle 等 SQL 與協議的支持，均經過插件的方式織入項目。 開發者可以像使用積木同樣定製屬於本身的獨特系統。Apache ShardingSphere 目前已提供數十個 SPI 做爲系統的擴展點，仍在不斷增長中。

​ ShardingSphere 已於2020年4月16日成爲 Apache 軟件基金會的頂級項目。

一、sharding-JDCB

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

• 適用於任何基於JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
• 支持任何第三方的數據庫鏈接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
• 支持任意實現JDBC規範的數據庫。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92標準的數據庫。

二、sharding-proxy

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

• 嚮應用程序徹底透明，可直接當作MySQL/PostgreSQL使用。
• 適用於任何兼容MySQL/PostgreSQL協議的的客戶端。
  

三、sharding-sidecar

​ 定位爲Kubernetes的雲原生數據庫代理，以Sidecar的形式代理全部對數據庫的訪問。 經過無中心、零侵入的方案提供與數據庫交互的的齧合層，即Database Mesh，又可稱數據網格。

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

四、三個組件的對比

五、混合架構

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

​ ShardingSphere是多接入端共同組成的生態圈。 經過混合使用Sharding-JDBC和Sharding-Proxy，並採用同一註冊中心統一配置分片策略，可以靈活的搭建適用於各類場景的應用系統，架構師能夠更加自由的調整適合於當前業務的最佳系統架構。

二、核心概念

一、邏輯表

​ 水平拆分的數據庫（表）的相同邏輯和數據結構表的總稱。例：訂單數據根據主鍵尾數拆分爲10張表，分別是t_order_0到t_order_9，他們的邏輯表名爲t_order。

二、真實表

​ 在分片的數據庫中真實存在的物理表。即上個示例中的t_order_0到t_order_9。

三、數據節點

​ 數據分片的最小單元。由數據源名稱和數據表組成，例：ds_0.t_order_0。

四、綁定表

​ 指分片規則一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，則此兩張表互爲綁定表關係。綁定表之間的多表關聯查詢不會出現笛卡爾積關聯，關聯查詢效率將大大提高。舉例說明，若是SQL爲：

SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

​ 在不配置綁定表關係時，假設分片鍵order_id將數值10路由至第0片，將數值11路由至第1片，那麼路由後的SQL應該爲4條，它們呈現爲笛卡爾積：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

​ 在配置綁定表關係後，路由的SQL應該爲2條：

SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in (10, 11);

​ 其中t_order在FROM的最左側，ShardingSphere將會以它做爲整個綁定表的主表。 全部路由計算將會只使用主表的策略，那麼t_order_item表的分片計算將會使用t_order的條件。故綁定表之間的分區鍵要徹底相同。

五、廣播表

​ 指全部的分片數據源中都存在的表，表結構和表中的數據在每一個數據庫中均徹底一致。適用於數據量不大且須要與海量數據的表進行關聯查詢的場景，例如：字典表。

六、分片鍵

​ 用於分片的數據庫字段，是將數據庫(表)水平拆分的關鍵字段。例：將訂單表中的訂單主鍵的尾數取模分片，則訂單主鍵爲分片字段。 SQL中若是無分片字段，將執行全路由，性能較差。 除了對單分片字段的支持，ShardingSphere也支持根據多個字段進行分片。

七、分片算法

​ 經過分片算法將數據分片，支持經過=、>=、<=、>、<、BETWEEN和IN分片。分片算法須要應用方開發者自行實現，可實現的靈活度很是高。

​ 目前提供4種分片算法。因爲分片算法和業務實現緊密相關，所以並未提供內置分片算法，而是經過分片策略將各類場景提煉出來，提供更高層級的抽象，並提供接口讓應用開發者自行實現分片算法。

• 精確分片算法

  對應PreciseShardingAlgorithm，用於處理使用單一鍵做爲分片鍵的=與IN進行分片的場景。須要配合StandardShardingStrategy使用。

• 範圍分片算法

  對應RangeShardingAlgorithm，用於處理使用單一鍵做爲分片鍵的BETWEEN AND、>、<、>=、<=進行分片的場景。須要配合StandardShardingStrategy使用。

• 複合分片算法

  對應ComplexKeysShardingAlgorithm，用於處理使用多鍵做爲分片鍵進行分片的場景，包含多個分片鍵的邏輯較複雜，須要應用開發者自行處理其中的複雜度。須要配合ComplexShardingStrategy使用。

• Hint分片算法

  對應HintShardingAlgorithm，用於處理使用Hint行分片的場景。須要配合HintShardingStrategy使用。

八、分片策略

​ 包含分片鍵和分片算法，因爲分片算法的獨立性，將其獨立抽離。真正可用於分片操做的是分片鍵 + 分片算法，也就是分片策略。目前提供5種分片策略。

• 標準分片策略

  對應StandardShardingStrategy。提供對SQL語句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操做支持。StandardShardingStrategy只支持單分片鍵，提供PreciseShardingAlgorithm和RangeShardingAlgorithm兩個分片算法。PreciseShardingAlgorithm是必選的，用於處理=和IN的分片。RangeShardingAlgorithm是可選的，用於處理BETWEEN AND, >, <, >=, <=分片，若是不配置RangeShardingAlgorithm，SQL中的BETWEEN AND將按照全庫路由處理。

• 複合分片策略

  對應ComplexShardingStrategy。複合分片策略。提供對SQL語句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操做支持。ComplexShardingStrategy支持多分片鍵，因爲多分片鍵之間的關係複雜，所以並未進行過多的封裝，而是直接將分片鍵值組合以及分片操做符透傳至分片算法，徹底由應用開發者實現，提供最大的靈活度。

• 行表達式分片策略

  對應InlineShardingStrategy。使用Groovy的表達式，提供對SQL語句中的=和IN的分片操做支持，只支持單分片鍵。對於簡單的分片算法，能夠經過簡單的配置使用，從而避免繁瑣的Java代碼開發，如: t_user_$->{u_id % 8} 表示t_user表根據u_id模8，而分紅8張表，表名稱爲t_user_0到t_user_7。

• Hint分片策略

  對應HintShardingStrategy。經過Hint指定分片值而非從SQL中提取分片值的方式進行分片的策略。

• 不分片策略

  對應NoneShardingStrategy。不分片的策略。