存儲-海量數據（ShardingSphere核心概念剖析和實戰）

目標

Ø 掌握數據庫的大數據處理方案和HA
Ø 掌握爲何須要數據庫中間件，何爲數據庫中間件
Ø 掌握不一樣場景所需的數據庫中間件特性
Ø 掌握數據庫中間件設計要點

 

Sharding-JDBC用途、使用場景、架構

認識ShardingSphere

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

當前版本：3.0
官網地址：https://shardingsphere.apache.org/index_zh.html
官方文檔：https://shardingsphere.apache.org/document/current/cn/overview/

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

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

Sharding-JDBC功能架構圖

認識Sharding-Proxy

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

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

認識Sharding-Proxy功能架構圖

三個組件對比認識

 

混合架構

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

ShardingSphere功能清單

數據分片：

Ø 分庫 & 分表
Ø 讀寫分離
Ø 分佈式主鍵

分佈式事務（doing）：

Ø XA強一致事務
Ø 柔性事務

數據庫治理：

Ø 配置動態化
Ø 熔斷 & 禁用
Ø 調用鏈路追蹤
Ø 彈性伸縮 (Planning)

ShardingSphere數據分片內核工做原理

ShardingSphere的3個產品的數據分片主要流程是徹底一致的 核心由SQL解析 => 執行器優化 => SQL路由 => SQL改寫 => SQL執行 => 結果歸併的流程組成

規劃路線圖

Sharding-JDBC配置使用

Sharding 課程小結- JDBC入門使用

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

內容參考：Sharding-JDBC入門使用.pdf

 

Sharding-JDBC分庫分表實戰

Sharding-JDBC分庫分表概念

邏輯表

水平拆分的數據庫（表）的相同邏輯和數據結構表的總稱。例：訂單數據根據主鍵%2拆分爲2張表，分 別是t_order0、t_order1，他們的邏輯表名爲t_order。

Sharding-JDBC分庫分表概念-數據節點

Sharding-JDBC分庫分表概念-分片策略

數據源分片、表分片僅是兩個不一樣維度的分片，它們能用的分片策略規則是同樣的。 Sharding-JDBC中提供了經常使用的分片策略實現。分片策略由兩部分構成：

Ø 分片鍵
Ø 分片算法

Sharding-JDBC提供的5種分片策略

none 不分片策略

對應NoneShardingStrategy ，不分片策略 ,SQL會被髮給全部節點去執行,這個規則沒有子項目能夠配置。

inline 行表達式分片策略  必掌握

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

databaseStrategy:
  inline:
  shardingColumn: user_id
  algorithmInlineExpression: ds${user_id % 2}

行表達式語法

Ø ${begin..end}表示範圍區間
Ø ${[unit1, unit2, unit_x]}表示枚舉值
Ø 行表達式中若是出現連續多個${ expression }或$->{ expression }表達式，整個表達式最終的結果將會根據每一個子表達式的結果進行笛卡爾組合。

standard 標準分片策略  需瞭解

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

databaseStrategy:
  standard: #單列sharidng算法,須要配合對應的preciseShardingAlgorithm,rangeShardingAlgorithm接口的實現使用
  shardingColumn: # 列名,容許單列
  preciseShardingAlgorithm: # preciseShardingAlgorithm接口的實現類
  rangeShardingAlgorithm: # rangeShardingAlgorithm接口的實現類

complex 複合分片策略 需瞭解

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

hint分片策略 需瞭解

Ø 對應HintShardingStrategy。經過Hint而非SQL解析的方式分片的策略。
Ø 對於分片字段非SQL決定，而由其餘外置條件決定的場景，可以使用SQL Hint靈活的注入分片字段。例：內部系統，按照員工登陸主鍵分庫，而數據庫中並沒有此字段。SQL Hint支持經過Java API和SQL註釋(待實現)兩種方式使用。

databaseStrategy:
  hint: #基於標記的sharding分片
    shardingAlgorithm: # 須要是HintShardingAlgorithm接口的實現,目前代碼中,有爲測試目的實現的OrderDatabaseHintShardingAlgorithm可參考

Sharding-JDBC配置默認數據源、分片策略

可配置默認的數據源、數據源分片策略、表分片策略 需瞭解

Sharding-JDBC—分佈式主鍵

分佈式主鍵

ShardingSphere提供靈活的配置分佈式主鍵生成策略方式。 在分片規則配置模塊可配置每一個表的主鍵生成策略，默認使用雪花算法（snowflake）生成64bit的長整型數據。
當前提供了 SNOWFLAKE、UUID 兩種可用方式。

Sharding-JDBC分庫分表概念-綁定表

綁定表

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

Sharding-JDBC分庫分表概念-綁定表示例

若是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的條件。故綁定表之間的分區鍵要徹底相同。

Sharding-JDBC分庫分表概念-廣播表

廣播表

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

shardingRule:
  broadcastTables:
    - t_config

 

Sharding-JDBC事務應用與數據治理

Sharding-JDBC-分佈式事務應用

Spring-boot-starter 方式

<dependency>
 <groupId>io.shardingsphere</groupId>
 <artifactId>sharding-transaction-spring-boot-starter</artifactId>
 <version>${sharding-sphere.version}</version>
</dependency>

業務代碼中應用

@ShardingTransactionType(TransactionType.LOCAL)
@Transactional

@ShardingTransactionType(TransactionType.XA)
@Transactional

注意：@ShardingTransactionType須要同Spring的@Transactional配套使用，事務纔會生效。

Atomikos參數配置

ShardingSphere默認的XA事務管理器爲Atomikos。 能夠經過在項目的classpath中添加jta.properties 來定製化Atomikos配置項。 具體的配置規則請參考Atomikos的官方文檔。

Sharding-JDBC-數據治理-配置中心

實現動機

Ø 配置集中心化：愈來愈多的運行時實例，使得散落的配置難於管理，配置不一樣步致使的問題分嚴重。將配置集中於配置中心，能夠更加有效進行管理。
Ø 配置動態化：配置修改後的分發，是配置中心能夠提供的另外一個重要能力。它可支持數據源、表與分片及讀寫分離策略的動態切換。

參考連接： https://shardingsphere.apache.org/document/current/cn/manual/shardingjdbc/usage/orchestration/