分庫分表之ShardingSphere

来源:https://www.cnblogs.com/donleo123/archive/2023/04/07/17295667.html
-Advertisement-
Play Games

為什麼要分庫分表 用戶請求量太大 單伺服器TPS、記憶體、IO都是有上限的，需要將請求打散分佈到多個伺服器 。 單庫數據量太大 單個資料庫處理能力有限；單庫所在伺服器的磁碟空間有限；單庫上的操作IO有瓶頸 。 單表數據量太大 查詢、插入、更新操作都會變慢，在加欄位、加索引、機器遷移都會產生高負載，影響 ...


為什麼要分庫分表

  • 用戶請求量太大

單伺服器TPS、記憶體、IO都是有上限的，需要將請求打散分佈到多個伺服器 。

  • 單庫數據量太大

單個資料庫處理能力有限；單庫所在伺服器的磁碟空間有限；單庫上的操作IO有瓶頸 。

  • 單表數據量太大

查詢、插入、更新操作都會變慢，在加欄位、加索引、機器遷移都會產生高負載，影響服務。

拆分方式

垂直拆分

  • 垂直分庫

微服務架構時，業務切割得足夠獨立，數據也按照業務切分，不同業務的數據存入不同的庫中。

  • 垂直分表

表中欄位太多且包含大欄位，可將這張大表拆分為多張表。

水平拆分

  • 水平分庫

將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。

  • 水平分庫規則

不跨庫、不跨表，保證同一類的數據都在同一個伺服器上面。

  • 水平分表

針對數據量巨大的單張表（比如訂單表），按照規則把一張表的數據切分到多張表裡面去。

  • 水平分表規則
  1. RANGE
  • 時間：按照年、月、日去切分。例如order_2022、order_202203、order_20220301
  • 地域：按照省或市去切分。例如order_beijing、order_shanghai、order_chengdu
  • 大小：從0到1000000一個表。例如1000001-2000000放一個表，每100萬放一個表
  1. HASH
  • 用戶ID取模
  1. 站內信
  • 用戶維度：用戶只能看到發送給自己的消息，其他用戶是不可見的，這種情況下是按照
  • 用戶ID hash分庫，在用戶查看歷史記錄翻頁查詢時，所有的查詢請求都在同一個庫內
  1. 用戶表
  • 範圍法：以用戶ID為劃分依據，將數據水平切分到兩個資料庫實例，如：1到1000W在 一張表，1000W到2000W在一張表，這種情況會出現單表的負載較高
  • 按照用戶ID HASH儘量保證用戶數據均衡分到資料庫中

...

面臨的問題

由於數據存儲在不同的庫和表中，也帶來了其他方面的一些問題，如下：

  • ID主鍵怎麼生成？
  • 數據怎麼保持一致？
  • 資料庫怎麼擴容？
  • 業務層代碼怎麼改造？

分頁排序、事務問題、跨表跨庫join問題等。

解決方案

主鍵選擇

  • UUID：本地生成，不依賴資料庫，缺點就是作為主鍵性能太差
  • SNOWFLAKE：雪花演算法

數據一致性

  • 強一致性：XA協議
  • 最終一致性：TCC、saga、Seata

資料庫擴容

  • 成倍增加數據節點，實現平滑擴容
  • 成倍擴容以後，表中的部分數據請求已被路由到其他節點上面，可以清理掉

業務層改造

  • 基於代理層方式：Mycat、Sharding-Proxy、MySQL Proxy
  • 基於應用層方式：Sharding-jdbc

跨庫跨表join問題

  • 全局表（字典表）：基礎數據/配置數據，所有庫都拷貝一份
  • 欄位冗餘：可以使用欄位冗餘就不用join查詢了
  • 系統層組裝：可以在業務層分別查詢出來，然後組裝起來，邏輯較複雜

中間件之ShardingSphere

簡介

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

ShardingSphere定位為關係型資料庫中間件，旨在充分合理地在分散式的場景下利用關係型資料庫的計算和存儲能力，而並非實現一個全新的關係型資料庫。

Sharding-JDBC：被定位為輕量級Java框架，在Java的JDBC層提供的額外服務，以jar包形式使用。

Sharding-Proxy：被定位為透明化的資料庫代理端，提供封裝了資料庫二進位協議的服務端版本，用於完成對異構語言的支持。

Sharding-Sidecar：被定位為Kubernetes或Mesos的雲原生資料庫代理，以DaemonSet的形式代理所有對資料庫的訪問。

Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar三者區別如下：

Sharding-JDBC

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主要功能：

  • 數據分片
  1. 分庫、分表
  2. 讀寫分離
  3. 分片策略
  4. 分散式主鍵
  • 分散式事務
  1. 標準化的事務介面
  2. XA強一致性事務
  3. 柔性事務
  • 資料庫治理
  1. 配置動態化
  2. 編排和治理
  3. 數據脫敏
  4. 可視化鏈路追蹤

Sharding-JDBC 使用過程

  • 引入maven依賴
<dependency> 
  <groupId>org.apache.shardingsphere</groupId> 
  <artifactId>sharding-jdbc-core</artifactId> 
  <version>${latest.release.version}</version> 
</dependency>
  • 規則配置

Sharding-JDBC可以通過Java，YAML，Spring命名空間和Spring Boot Starter四種方式配置，開發者可根據場景選擇適合的配置方式。

  • 創建DataSource

通過ShardingDataSourceFactory工廠和規則配置對象獲取ShardingDataSource，然後即可通過DataSource選擇使用原生JDBC開發，或者使用JPA, MyBatis等ORM工具。

DataSource dataSource = ShardingDataSourceFactory.createDataSource(dataSourceMap, 
shardingRuleConfig, props);

數據分片

核心概念

表概念

  • 真實表

資料庫中真實存在的物理表。例如b_order0、b_order1

  • 邏輯表

在分片之後，同一類表結構的名稱（總成）。例如b_order。

  • 數據節點

在分片之後，由數據源和數據表組成。例如ds0.b_order1

  • 綁定表

指的是分片規則一致的關係表（主表、子表），例如b_order和b_order_item，均按照order_id分片，則此兩個表互為綁定表關係。綁定表之間的多表關聯查詢不會出現笛卡爾積關聯，可以提升關聯查詢效率。

b_order：b_order0、b_order1 
b_order_item：b_order_item0、b_order_item1 

select * from b_order o join b_order_item i on(o.order_id=i.order_id) 
where o.order_id in (10,11);

如果不配置綁定表關係，採用笛卡爾積關聯，會生成4個SQL

select * from b_order0 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order0 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11);

如果配置綁定表關係，生成2個SQL

select * from b_order0 o join b_order_item0 i on(o.order_id=i.order_id) 
where o.order_id in (10,11); 

select * from b_order1 o join b_order_item1 i on(o.order_id=i.order_id) 
where o.order_id in (10,11);
  • 廣播表

在使用中，有些表沒必要做分片，例如字典表、省份信息等，因為他們數據量不大，而且這種表可能需要與海量數據的表進行關聯查詢。廣播表會在不同的數據節點上進行存儲，存儲的表結構和數據完全相同。

  • 邏輯索引

某些資料庫（如：PostgreSQL）不允許同一個庫存在名稱相同索引，某些資料庫（如：MySQL）則允許只要同一個表中不存在名稱相同的索引即可。 邏輯索引用於同一個庫不允許出現相同索引名稱的分表場景，需要將同庫不同表的索引名稱改寫為索引名 + 表名，改寫之前的索引名稱成為邏輯索引。

分片鍵

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

分片演算法（ShardingAlgorithm）

通過分片演算法將數據分片，支持通過=、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。不分片的策略。

分片策略配置

對於分片策略存有數據源分片策略和表分片策略兩種維度，兩種策略的API完全相同。

  • 數據源分片策略

用於配置數據被分配的目標數據源。

  • 表分片策略

用於配置數據被分配的目標表，由於表存在與數據源內，所以表分片策略是依賴數據源分片策略結果的。

流程剖析

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

  • SQL解析

分為詞法解析和語法解析。 先通過詞法解析器將SQL拆分為一個個不可再分的單詞。再使用語法解析器對SQL進行理解，並最終提煉出解析上下文。 解析上下文包括表、選擇項、排序項、分組項、聚合函數、分頁信息、查詢條件以及可能需要修改的占位符的標記。

  • 執行器優化

合併和優化分片條件，如OR等。

  • SQL路由

根據解析上下文匹配用戶配置的分片策略，並生成路由路徑。目前支持分片路由和廣播路由。

  • SQL改寫

將SQL改寫為在真實資料庫中可以正確執行的語句。SQL改寫分為正確性改寫和優化改寫。

  • SQL執行

通過多線程執行器非同步執行。

  • 結果歸併

將多個執行結果集歸併以便於通過統一的JDBC介面輸出。結果歸併包括流式歸併、記憶體歸併和使用裝飾者模式的追加歸併這幾種方式。

SQL使用規範

支持項

路由至單數據節點時，目前MySQL資料庫100%全相容，其他資料庫完善中。

路由至多數據節點時，全面支持DQL、DML、DDL、DCL、TCL。支持分頁、去重、排序、分組、聚合、關聯查詢（不支持跨庫關聯）。

  • SELECT主語句
SELECT select_expr [, select_expr ...] FROM table_reference [, table_reference ...]
[WHERE where_condition] 
[GROUP BY {col_name | position} [ASC | DESC]] 
[ORDER BY {col_name | position} [ASC | DESC], ...] 
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
  • select_expr
* | 
[DISTINCT] COLUMN_NAME [AS] [alias] | 
(MAX | MIN | SUM | AVG)(COLUMN_NAME | alias) [AS] [alias] | 
COUNT(* | COLUMN_NAME | alias) [AS] [alias]
  • table_reference
tbl_name [AS] alias] [index_hint_list] | 
table_reference ([INNER] | {LEFT|RIGHT} [OUTER]) JOIN table_factor [JOIN ON conditional_expr | USING (column_list)] |

不支持項

不支持CASE WHEN、HAVING、UNION (ALL)

  • 支持分頁子查詢，但其他子查詢有限支持，無論嵌套多少層，只能解析至第一個包含數據表的子查詢，一旦在下層嵌套中再次找到包含數據表的子查詢將直接拋出解析異常。

例如，以下子查詢可以支持： 

SELECT COUNT(*) FROM (SELECT * FROM b_order o)

以下子查詢不支持： 

SELECT COUNT(*) FROM (SELECT * FROM b_order o WHERE o.id IN (SELECT id 
FROM b_order WHERE status = ?))

簡單來說，通過子查詢進行非功能需求，在大部分情況下是可以支持的。比如分頁、統計總數等；而通過子查詢實現業務查詢當前並不能支持。

  • 由於歸併的限制，子查詢中包含聚合函數目前無法支持。
  • 不支持包含schema的SQL。因為ShardingSphere的理念是像使用一個數據源一樣使用多數據源，因此對SQL的訪問都是在同一個邏輯schema之上。
  • 當分片鍵處於運算表達式或函數中的SQL時，將採用全路由的形式獲取結果。

例如下麵SQL，create_time為分片鍵：

SELECT * FROM b_order WHERE to_date(create_time, 'yyyy-mm-dd') = '2020-05-05';

由於ShardingSphere只能通過SQL字面提取用於分片的值，因此當分片鍵處於運算表達式或函數中時，ShardingSphere無法提前獲取分片鍵位於資料庫中的值，從而無法計算出真正的分片值。

分頁查詢

完全支持MySQL和Oracle的分頁查詢，SQLServer由於分頁查詢較為複雜，僅部分支持.

  • 性能瓶頸

查詢偏移量過大的分頁會導致資料庫獲取數據性能低下，以MySQL為例： 

SELECT * FROM b_order ORDER BY id LIMIT 1000000, 10

這句SQL會使得MySQL在無法利用索引的情況下跳過1000000條記錄後，再獲取10條記錄，其性能可想而知。 而在分庫分表的情況下（假設分為2個庫），為了保證數據的正確性，SQL會改寫為：

SELECT * FROM b_order ORDER BY id LIMIT 0, 1000010

即將偏移量前的記錄全部取出，並僅獲取排序後的最後10條記錄。這會在資料庫本身就執行很慢的情況下，進一步加劇性能瓶頸。 因為原SQL僅需要傳輸10條記錄至客戶端，而改寫之後的SQL則會傳輸1,000,010 * 2的記錄至客戶端。

  • ShardingSphere的優化

ShardingSphere進行了以下2個方面的優化。

  1. 首先，採用流式處理 + 歸併排序的方式來避免記憶體的過量占用。
  2. 其次，ShardingSphere對僅落至單節點的查詢進行進一步優化。
  • 分頁方案優化

由於LIMIT並不能通過索引查詢數據，因此如果可以保證ID的連續性，通過ID進行分頁是比較好的解決方案：

SELECT * FROM b_order WHERE id > 1000000 AND id <= 1000010 ORDER BY id

或通過記錄上次查詢結果的最後一條記錄的ID進行下一頁的查詢

SELECT * FROM b_order WHERE id > 1000000 LIMIT 10

其它功能

  • Inline行表達式

InlineShardingStrategy：採用Inline行表達式進行分片的配置。

Inline是可以簡化數據節點和分片演算法配置信息。主要是解決配置簡化、配置一體化。

  • 語法格式

行表達式的使用非常直觀，只需要在配置中使用${ expression }或$->{ expression }標識行表達式即可。例如：

${begin..end} 表示範圍區間 
${[unit1, unit2, unit_x]} 表示枚舉值

行表達式中如果出現多個${}或$->{}表達式，整個表達式結果會將每個子表達式結果進行笛卡爾(積)組合。例如，以下行表達式：

${['online', 'offline']}_table${1..3} 
$->{['online', 'offline']}_table$->{1..3}

最終會解析為： 

online_table1, online_table2, online_table3, 
offline_table1, offline_table2, offline_table3
  • 數據節點配置

對於均勻分佈的數據節點，如果數據結構如下： 

db0
├── b_order2 
└── b_order1 
db1
├── b_order2 
└── b_order1

用行表達式可以簡化為： 

db${0..1}.b_order${1..2}

或者

db$->{0..1}.b_order$->{1..2}

對於自定義的數據節點，如果數據結構如下： 

db0
├── b_order0 
└── b_order1 
db1
├── b_order2 
├── b_order3 
└── b_order4

用行表達式可以簡化為： 

db0.b_order${0..1},db1.b_order${2..4}
  • 分片演算法配置

行表達式內部的表達式本質上是一段Groovy代碼，可以根據分片鍵進行計算的方式，返回相應的

真實數據源或真實表名稱。

ds${id % 10} 
或者
ds$->{id % 10}

結果為：ds0、ds1、ds2... ds9

  • 分散式主鍵

ShardingSphere不僅提供了內置的分散式主鍵生成器，例如UUID、SNOWFLAKE，還抽離出分佈式主鍵生成器的介面，方便用戶自行實現自定義的自增主鍵生成器。

  • 內置主鍵生成器
  1. UUID ：採用UUID.randomUUID()的方式產生分散式主鍵。
  2. SNOWFLAKE ：在分片規則配置模塊可配置每個表的主鍵生成策略，預設使用雪花演算法，生成64bit的長整型 數據。
  • 自定義主鍵生成器
  • 自定義主鍵類，實現ShardingKeyGenerator介面
  • 按SPI規範配置自定義主鍵類

在Apache ShardingSphere中，很多功能實現類的載入方式是通過SPI註入的方式完成的。

註意：在resources目錄下新建META-INF文件夾，再新建services文件夾，然後新建文件的名字為org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator，打開文件，複製自定義主鍵類全路徑到文件中保存。

  • 自定義主鍵類應用配置

#對應主鍵欄位名 

spring.shardingsphere.sharding.tables.t_book.key-generator.column=id

#對應主鍵類getType返回內容 

spring.shardingsphere.sharding.tables.t_book.key-generator.type=LAGOUKEY

讀寫分離

讀寫分離是通過主從的配置方式，將查詢請求均勻的分散到多個數據副本，進一步的提升系統的處理能力。

  • 主從架構：讀寫分離，目的是高可用、讀寫擴展。主從庫內容相同，根據SQL語義進行路由。
  • 分庫分表架構：數據分片，目的讀寫擴展、存儲擴容。庫和表內容不同，根據分片配置進行路由。

將水平分片和讀寫分離聯合使用，能夠更加有效的提升系統性能，

下圖展現了將分庫分表與讀寫分離一同使用時，應用程式與資料庫集群之間的複雜拓撲關係。

讀寫分離雖然可以提升系統的吞吐量和可用性，但同時也帶來了數據不一致的問題，包括多個主庫之間 的數據一致性，以及主庫與從庫之間的數據一致性的問題。 並且，讀寫分離也帶來了與數據分片同樣的 問題，它同樣會使得應用開發和運維人員對資料庫的操作和運維變得更加複雜。

讀寫分離應用方案

在數據量不是很多的情況下，我們可以將資料庫進行讀寫分離，以應對高併發的需求，通過水平擴展從 庫，來緩解查詢的壓力。如下：

分表+讀寫分離

在數據量達到500萬的時候，這時數據量預估千萬級別，我們可以將數據進行分表存儲。

分庫分表+讀寫分離

在數據量繼續擴大，這時可以考慮分庫分表，將數據存儲在不同資料庫的不同表中，如下：

透明化讀寫分離所帶來的影響，讓使用方儘量像使用一個資料庫一樣使用主從資料庫集群，是ShardingSphere讀寫分離模塊的主要設計目標。

主庫、從庫、主從同步、負載均衡

核心功能

  • 提供一主多從的讀寫分離配置。僅支持單主庫，可以支持獨立使用，也可以配合分庫分表使用獨立使用讀寫分離，支持SQL透傳。不需要SQL改寫流程
  • 同一線程且同一資料庫連接內，能保證數據一致性。如果有寫入操作，後續的讀操作均從主庫讀取。
  • 基於Hint的強制主庫路由。可以強制路由走主庫查詢實時數據，避免主從同步數據延遲。

不支持項

  • 主庫和從庫的數據同步
  • 主庫和從庫的數據同步延遲
  • 主庫雙寫或多寫
  • 跨主庫和從庫之間的事務的數據不一致。建議在主從架構中，事務中的讀寫均用主庫操作。

主從複製原理

MySQL里有一個概念，叫binlog日誌，就是每個增刪改類的操作，會改變數據的操作，除了更新數據以外，對這個增刪改操作還會寫入一個日誌文件，記錄這個操作的日誌。

主庫將變更寫binlog日誌，然後從庫連接到主庫之後，從庫有一個IO線程，將主庫的binlog日誌拷貝到自己本地，寫入一個中繼日誌中。接著從庫中有一個SQL線程會從中繼日誌讀取binlog，然後執行binlog日誌中的內容，也就是在自己本地再次執行一遍SQL，這樣就可以保證自己跟主庫的數據是一樣的。

這裡有一個非常重要的一點，就是從庫同步主庫數據的過程是串列化的，也就是說主庫上並行的操作，在從庫上會串列執行。所以這就是一個非常重要的點了，由於從庫從主庫拷貝日誌以及串列執行SQL的特點，在高併發場景下，從庫的數據一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的數據可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。

而且這裡還有另外一個問題，就是如果主庫突然宕機，然後恰好數據還沒同步到從庫，那麼有些數據可能在從庫上是沒有的，有些數據可能就丟失了。

所以mysql實際上在這一塊有兩個機制，一個是半同步複製，用來解決主庫數據丟失問題；一個是並行複製，用來解決主從同步延時問題。

這個所謂半同步複製，semi-sync複製，指的就是主庫寫入binlog日誌之後，就會將強制此時立即將數據同步到從庫，從庫將日誌寫入自己本地的relay log之後，接著會返回一個ack給主庫，主庫接收到至少一個從庫的ack之後才會認為寫操作完成了。

所謂並行複製，指的是從庫開啟多個線程，並行讀取relay log中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。

 

官方文檔地址：https://shardingsphere.apache.org/document/legacy/3.x/document/cn/overview/

 

 

作者：donleo123 出處：https://www.cnblogs.com/donleo123/ 本文如對您有幫助，還請多推薦下此文，如有錯誤歡迎指正，相互學習，共同進步。
您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 概念：四種基於模型的嵌入式軟體開發、測試與驗證方法
    ​ 嵌入式軟體（如航空電子和汽車系統）的設計、開發、測試和驗證正變得越來越複雜。傳統的文檔驅動式環境中，一旦開發人員之間缺乏協調，軟體程式生命周期的質量和成本就會受到嚴重影響，顯然已經無法應對日益複雜的嵌入式軟體生產。 正確使用基於模型的設計（Model-Based Design，以下簡稱MBD）方 ...
  • Linux許可權掌控
    無論是Window，MacOs，Linux均採用多用戶的管理模式進行許可權管理。 在Linux系統中，擁有最大許可權的賬戶名為：root（超級管理員）。 root用戶擁有最大的系統操作許可權，而普通用戶在許多地方的許可權是受限的。 普通用戶一般在HOME目錄是不受限制的，一旦出了HOME目錄，大多地方，僅有 ...
  • 05-Esp8266物聯網晶元的使用（一）-part01-ESP8266引腳
    主要內容 晶元介紹 開發環境 編程舉例 晶元介紹 什麼是NodeMCU？ NodeMCU,是一個開源的物聯網平臺。 它使用Lua腳本語言編程。該平臺基於eLua 開源項目,底層使用ESP8266 sdk 0.9.5版本。該平臺使用了很多開源項目, 例如 lua-cjson, spiffs. Node ...
  • 面試題百日百刷-HBase HRegionServer宕機如何處理
    鎖屏面試題百日百刷，每個工作日堅持更新面試題。鎖屏面試題app、小程式現已上線，官網地址：https://www.demosoftware.cn。已收錄了每日更新的面試題的所有內容，還包含特色的解鎖屏幕複習面試題、每日編程題目郵件推送等功能。讓你在面試中先人一步!接下來的是今日的面試題： 1.HBa ...
  • mysql+navicat安裝配置教程
    一、MySQLl和Navicat的關係 Mysql一個關係型資料庫管理系統，由瑞典MysqlLAB公司開發，目前屬於Oracle旗下產品，是目前最流行的關心型資料庫管理系統之一。 Navicat一個資料庫管理工具，用可視化界面提供給用戶操作Mysql資料庫管理系統。 記得我第一次安裝Navicat之 ...
  • 詳解 Flink Catalog 在 ChunJun 中的實踐之路
    我們知道 Flink 有Table（表）、View（視圖）、Function（函數/運算元）、Database（資料庫）的概念，相對於這些耳熟能詳的概念，Flink 里還有一個 Catalog（目錄） 的概念。 本文將為大家帶來 Flink Catalog 的介紹以及 Flink Catalog 在 ...
  • hadoop學習記錄
    Hadoop簡介安裝 狹義上Hadoop指的是Apache軟體基金會的一款開源軟體用java語言實現，開源允許用戶使用簡單的編程模型實現跨機器集群對海量數據進行分散式計算處理 Hadoop核心組件 Hadoop HDFS（分散式文件存儲系統）：解決海量數據存儲 Hadoop YARN（集群資源管理和 ...
  • GaussDB（DWS）集群中尋找節點CPU占用高的語句
    摘要：本文主要通過實例講解如何通過gs_cpuwatcher.sh 腳本尋找CPU占用高語句。 本文分享自華為雲社區《GaussDB(DWS) gs_cpuwatcher.sh 腳本如何尋找CPU占用高語句》，作者：fighttingman。 【工具名稱】 gs_cpuwatcher 【功能描述】 ...
一周排行
    -Advertisement-
    Play Games
  • C# + WPF 音頻播放器 界面優雅，體驗良好
    前言 本文介紹一款使用 C# 與 WPF 開發的音頻播放器，其界面簡潔大方，操作體驗流暢。該播放器支持多種音頻格式（如 MP4、WMA、OGG、FLAC 等），並具備標記、實時歌詞顯示等功能。 另外，還支持換膚及多語言（中英文）切換。核心音頻處理採用 FFmpeg 組件，獲得了廣泛認可，目前 Git ...
  • OAuth2.0授權-gitee授權碼模式
    OAuth2.0授權驗證-gitee授權碼模式 本文主要介紹如何筆者自己是如何使用gitee提供的OAuth2.0協議完成授權驗證並登錄到自己的系統，完整模式如圖 1、創建應用 打開gitee個人中心->第三方應用->創建應用 創建應用後在我的應用界面，查看已創建應用的Client ID和Clien ...
  • FastReport.OpenSource .Net下開源免費報表列印組件
    解決了這個問題：《winForm下，fastReport.net 從.net framework 升級到.net5遇到的錯誤“Operation is not supported on this platform.”》 本文內容轉載自：https://www.fcnsoft.com/Home/Sho ...
  • 如何在 ASP.NET Core Web API 方法執行前後 “偷偷“ 作一些 “壞“ 事？初識 ActionFilterAttribute
    國內文章 WPF 從裸 Win 32 的 WM_Pointer 消息獲取觸摸點繪製筆跡 https://www.cnblogs.com/lindexi/p/18390983 本文將告訴大家如何在 WPF 裡面，接收裸 Win 32 的 WM_Pointer 消息，從消息裡面獲取觸摸點信息，使用觸摸點 ...
  • 在 ASP.NET Core Web API 中使用異常篩選器捕獲和統一處理異常
    前言 給大家推薦一個專為新零售快消行業打造了一套高效的進銷存管理系統。 系統不僅具備強大的庫存管理功能，還集成了高性能的輕量級 POS 解決方案，確保頁面載入速度極快，提供良好的用戶體驗。 項目介紹 Dorisoy.POS 是一款基於 .NET 7 和 Angular 4 開發的新零售快消進銷存管理 ...
  • AbpHelper CLI積累與實戰分享
    ABP CLI常用的代碼分享 一、確保環境配置正確 安裝.NET CLI： ABP CLI是基於.NET Core或.NET 5/6/7等更高版本構建的，因此首先需要在你的開發環境中安裝.NET CLI。這可以通過訪問Microsoft官網下載並安裝相應版本的.NET SDK來實現。 安裝ABP ...
  • 記一次HttpClient使用問題分析
    問題 問題是這樣的：第三方的webapi，需要先調用登陸介面獲取Cookie，訪問其它介面時攜帶Cookie信息。 但使用HttpClient類調用登陸介面，返回的Headers中沒有找到Cookie信息。 分析 首先，使用Postman測試該登陸介面，正常返回Cookie信息，說明是HttpCli ...
  • .NET周刊【9月第3期 2024-09-15】
    國內文章 關於.NET在中國為什麼工資低的分析 https://www.cnblogs.com/thinkingmore/p/18406244 .NET在中國開發者的薪資偏低，主要因市場需求、技術棧選擇和企業文化等因素所致。歷史上，.NET曾因微軟的閉源策略發展受限，儘管後來推出了跨平臺的.NET ...
  • 我的網站集成ElasticSearch初體驗
    在WPF開發應用中，動畫不僅可以引起用戶的註意與興趣，而且還使軟體更加便於使用。前面幾篇文章講解了畫筆（Brush），形狀（Shape），幾何圖形（Geometry），變換（Transform）等相關內容，今天繼續講解動畫相關內容和知識點，僅供學習分享使用，如有不足之處，還請指正。 ...
  • 第23篇 委托的概述
    什麼是委托？ 委托可以說是把一個方法代入另一個方法執行，相當於指向函數的指針；事件就相當於保存委托的數組； 1.實例化委托的方式： 方式1：通過new創建實例： public delegate void ShowDelegate(); 或者 public delegate string ShowDe ...
所有分類