Sharding-Sphere的分享

hanyue99s

694人浏览 · 2026-01-24 08:40:37

hanyue99s · 2026-01-24 08:40:37 发布

Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能，可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。

官网：http://shardingsphere.apache.org/index_zh.html
官方文档：https://shardingsphere.apache.org/document/legacy/3.x/document/cn/overview/
官方demo：https://github.com/apache/incubator-shardingsphere-example
码云：https://gitee.com/Sharding-Sphere/sharding-sphere

ShardingSphere 整合 Seata AT 分布式事务：https://www.infoq.cn/article/w6WKHscKTPa3-QMQI4gR

	Sharding-JDBC	Sharding-Proxy	Sharding-Sidecar
数据库	任意	MySQL	MySQL
连接消耗数	高	低	高
异构语言	仅Java	任意	任意
性能	损耗低	损耗略高	损耗低
无中心化	是	否	是
静态入口	无	有	无

概念 & 功能

单一数据库实例的数据的阈值在1TB之内，是比较合理的范围

数据分片

垂直分片：专库专用
水平分片：相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。

SQL

例：订单数据根据主键尾数拆分为10张表，分别是t_order_0到t_order_9，他们的逻辑表名为t_order

逻辑表
真实表
数据节点 ds_0.t_order_0
绑定表（指分片规则一致的主表和子表。例如：t_order表和t_order_item表，均按照order_id分片，则此两张表互为绑定表关系。JOIN时所有路由计算将会只使用主表的策略）
广播表（指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致。比如字典表）
逻辑索引（某些数据库（如：PostgreSQL）不允许同一个库存在名称相同索引，某些数据库（如：MySQL）则允许只要同一个表中不存在名称相同的索引即可。逻辑索引用于同一个库不允许出现相同索引名称的分表场景，需要将同库不同表的索引名称改写为索引名 + 表名，改写之前的索引名称成为逻辑索引。）

分片

订单主键为分片字段
支持根据多个字段进行分片

分片算法
通过分片算法将数据分片，支持通过=、BETWEEN和IN分片。分片算法需要应用方开发者自行实现。目前提供4种分片算法。

精确分片算法
对应PreciseShardingAlgorithm，用于处理使用单一键作为分片键的=与IN进行分片的场景。需要配合StandardShardingStrategy使用。
范围分片算法
对应RangeShardingAlgorithm，用于处理使用单一键作为分片键的BETWEEN AND进行分片的场景。需要配合StandardShardingStrategy使用。
复合分片算法
对应ComplexKeysShardingAlgorithm，用于处理使用多键作为分片键进行分片的场景，包含多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。需要配合ComplexShardingStrategy使用。
Hint分片算法
对应HintShardingAlgorithm，用于处理使用Hint行分片的场景。需要配合HintShardingStrategy使用。

分片策略
5种分片策略

标准分片策略
对应StandardShardingStrategy。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。不分片的策略。

SQL Hint
对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据库中并无此字段。SQL Hint支持通过Java API和SQL注释(待实现)两种方式使用。

配置

分片规则
数据源配置
表配置
数据节点配置
分片策略配置
DatabaseShardingStrategy。用于配置数据被分配的目标数据源。
TableShardingStrategy。用于配置数据被分配的目标表，该目标表存在与该数据的目标数据源内。故表分片策略是依赖与数据源分片策略的结果的。
自增主键生成策略
Config Map

内核剖析

SQL解析 => 执行器优化 => SQL路由 => SQL改写 => SQL执行 => 结果归并

解析引擎

词法解析器用于将SQL拆解为不可再分的原子符号，称为Token
语法解析器将SQL转换为抽象语法树

SQL解析引擎
第三代SQL解析器则从3.0.x版本开始，ShardingSphere尝试使用ANTLR作为SQL解析的引擎，并计划根据DDL -> TCL -> DAL –> DCL -> DML –>DQL这个顺序，依次替换原有的解析引擎，目前仍处于替换迭代中。
ANTLR解析SQL的性能比自研的SQL解析引擎慢3-10倍左右。为了弥补这一差距，ShardingSphere将使用PreparedStatement的SQL解析的语法树放入缓存。因此建议采用PreparedStatement这种SQL预编译的方式提升性能。

路由引擎

分片策略通常可以采用由数据库内置或由用户方配置。数据库内置的方案较为简单，内置的分片策略大致可分为尾数取模、哈希、范围、标签、时间等。

分片路由（细分为直接路由、标准路由和笛卡尔积路由）

广播路由（划分为全库路由、全库表路由、全实例路由、单播路由和阻断路由）
全库路由用于处理对数据库的操作，包括用于库设置的SET类型的数据库管理命令，以及TCL这样的事务控制语句。

全库表路由用于处理对数据库中与其逻辑表相关的所有真实表的操作，主要包括不带分片键的DQL和DML，以及DDL等。

全实例路由用于DCL操作，授权语句针对的是数据库的实例。无论一个实例中包含多少个Schema，每个数据库的实例只执行一次。

单播路由用于获取某一真实表信息的场景，它仅需要从任意库中的任意真实表中获取数据即可。

DESCRIBE t_order;

阻断路由用于屏蔽SQL对数据库的操作

USE order_db;

改写引擎

ShardingSphere目前还不支持在DQL和DML语句中使用Schema。它目前仅支持在数据库管理语句中使用Schema，例如：

SHOW COLUMNS FROM t_order FROM order_ds;

ShardingSphere提供了分布式自增主键的生成策略，并且可以通过补列，让使用方无需改动现有代码，即可将分布式自增主键透明的替换数据库现有的自增主键。

ShardingSphere暂时还未实现 in 条件拆分的改写策略

执行引擎

独立的数据库连接，能够持有查询结果集游标位置的引用，在需要获取相应数据时移动游标即可。

以结果集游标下移进行结果归并的方式，称之为流式归并，它无需将结果数据全数加载至内存，可以有效的节省内存资源，进而减少垃圾回收的频次.当无法保证每个分片查询持有一个独立数据库连接时，则需要在复用该数据库连接获取下一张分表的查询结果集之前，将当前的查询结果集全数加载至内存。因此，即使可以采用流式归并，在此场景下也将退化为内存归并。

内存限制模式（MEMORY_STRICTLY）
优先选择流式归并，以防止出现内存溢出或避免频繁垃圾回收情况。
OLAP 联机分析处理系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

连接限制模式（CONNECTION_STRICTLY）
该模式始终选择内存归并
OLTP 联机事务处理系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；

自动化执行引擎将连接模式的选择粒度细化至每一次SQL的操作。
每一次的连接模式的选择，是针对每一个物理数据库的。也就是说，在同一次查询中，如果路由至一个以上的数据库，每个数据库的连接模式不一定一样，它们可能是混合存在的形态。

为避免死锁，ShardingSphere在这里进行了2点优化：避免锁定一次性只需要获取1个数据库连接的操作；仅针对内存限制模式时才进行资源锁定。

执行引擎仅关注事件的发送，它并不关心事件的订阅者。 ShardingSphere的其他模块，如：分布式事务、调用链路追踪等，会订阅感兴趣的事件，并进行相应的处理。

归并引擎

功能上分为遍历、排序、分组、分页和聚合5种类型，它们是组合而非互斥的关系。

从结构划分，可分为流式归并、内存归并和装饰者归并。流式归并和内存归并是互斥的，装饰者归并可以在流式归并和内存归并之上做进一步的处理。

流式分组归并要求SQL的排序项与分组项的字段以及排序类型（ASC或DESC）必须保持一致，否则只能通过内存归并才能保证其数据的正确性。

使用规范

ShardingSphere所支持和不支持的SQL类型

不支持冗余括号、CASE WHEN、HAVING、UNION (ALL)，有限支持子查询。

不支持包含schema的SQL。因为ShardingSphere的理念是像使用一个数据源一样使用多数据源，因此对SQL的访问都是在同一个逻辑schema之上。

SQL

支持的SQL

SQL	必要条件
SELECT * FROM tbl_name
SELECT * FROM tbl_name WHERE (col1 = ? or col2 = ?) and col3 = ?
SELECT * FROM tbl_name WHERE col1 = ? ORDER BY col2 DESC LIMIT ?
SELECT COUNT(*), SUM(col1), MIN(col1), MAX(col1), AVG(col1) FROM tbl_name WHERE col1 = ?
SELECT COUNT(col1) FROM tbl_name WHERE col2 = ? GROUP BY col1 ORDER BY col3 DESC LIMIT ?, ?
INSERT INTO tbl_name (col1, col2,…) VALUES (?, ?, ….)
INSERT INTO tbl_name VALUES (?, ?,….)
INSERT INTO tbl_name (col1, col2, …) VALUES (?, ?, ….), (?, ?, ….)
UPDATE tbl_name SET col1 = ? WHERE col2 = ?
DELETE FROM tbl_name WHERE col1 = ?
CREATE TABLE tbl_name (col1 int, …)
ALTER TABLE tbl_name ADD col1 varchar(10)
DROP TABLE tbl_name
TRUNCATE TABLE tbl_name
CREATE INDEX idx_name ON tbl_name
DROP INDEX idx_name ON tbl_name
DROP INDEX idx_name	TableRule中配置logic-index
SELECT DISTINCT * FROM tbl_name WHERE col1 = ?
SELECT COUNT(DISTINCT col1) FROM tbl_name

不支持的SQL

SQL	不支持原因
INSERT INTO tbl_name (col1, col2, …) SELECT col1, col2, … FROM tbl_name WHERE col3 = ?	INSERT … SEL
INSERT INTO tbl_name SET col1 = ?	INSERT … SET
SELECT COUNT(col1) as count_alias FROM tbl_name GROUP BY col1 HAVING count_alias > ?	HAVING
SELECT * FROM tbl_name1 UNION SELECT * FROM tbl_name2	UNION
SELECT * FROM tbl_name1 UNION ALL SELECT * FROM tbl_name2	UNION ALL
SELECT * FROM tbl_name1 WHERE (val1=?) AND (val1=?)	冗余括号(MySQL数据库已支持)
SELECT * FROM ds.tbl_name1	包含schema
SELECT SUM(DISTINCT col1), SUM(col1) FROM tbl_name	详见DISTINCT支持情况详细说明

DISTINCT支持情况详细说明
支持的SQL

SQL	所需条件
SELECT DISTINCT * FROM tbl_name WHERE col1 = ?
SELECT DISTINCT col1 FROM tbl_name
SELECT DISTINCT col1, col2, col3 FROM tbl_name
SELECT DISTINCT col1 FROM tbl_name ORDER BY col1
SELECT DISTINCT col1 FROM tbl_name ORDER BY col2
SELECT DISTINCT(col1) FROM tbl_name	MySQL
SELECT AVG(DISTINCT col1) FROM tbl_name	MySQL
SELECT SUM(DISTINCT col1) FROM tbl_name	MySQL
SELECT COUNT(DISTINCT col1) FROM tbl_name	MySQL
SELECT COUNT(DISTINCT col1) FROM tbl_name GROUP BY col1	MySQL
SELECT COUNT(DISTINCT col1 + col2) FROM tbl_name	MySQL
SELECT COUNT(DISTINCT col1), SUM(DISTINCT col1) FROM tbl_name	MySQL
SELECT COUNT(DISTINCT col1), col1 FROM tbl_name GROUP BY col1	MySQL
SELECT col1, COUNT(DISTINCT col1) FROM tbl_name GROUP BY col1	MySQL

不支持的SQL

SQL	不支持原因
SELECT SUM(DISTINCT col1), SUM(col1) FROM tbl_name	同时使用普通聚合函数和DISTINCT聚合函数

分页

完全支持MySQL、PostgreSQL和Oracle的分页查询，SQLServer由于分页查询较为复杂，仅部分支持。

分页性能
查询偏移量过大的分页会导致数据库获取数据性能低下的问题，shardingsphere采用流式处理+归并排序，并且不对落至单片的请求进行sql改写。

由于++LIMIT并不能通过索引查询++数据，因此如果可以保证ID的连续性，通过ID进行分页是比较好的解决方案。

分页子查询
Oracle和SQLServer的分页都需要通过子查询来处理，ShardingSphere支持分页相关的子查询。

其他功能

行表达式

数据节点和分片算法这两个部分的配置。行表达式的内容使用的是Groovy的语法，Groovy能够支持的所有操作，行表达式均能够支持。

${begin…end}表示范围区间
${[unit1, unit2, unit_x]}表示枚举值

配置数据节点:

db ${0..1}.t_order_0$ {0…9}, db $KaTeX parse error: Expected group after '_' at position 15: {0..1}.t_order_̲$ {10…20}

配置分片算法:
对于只有一个分片键的使用=和IN进行分片的SQL，可以使用行表达式代替编码方式配置。

ds${id % 10}

分布式主键

ShardingSphere采用以接口来实现对于生成主键的访问，而将底层具体的主键生成实现分离出来。
默认分布式主键生成器
雪花算法（snowflake）生成64bit的长整型数据
在同一个进程中，它首先是通过++时间位保证不重复++，如果时间相同则是通过序列位保证。同时由于时间位是单调递增的，且各个服务器如果大体做了时间同步，那么生成的主键在分布式环境++可以认为是总体有序++的，这就保证了对索引字段的插入的高效性。

使用雪花算法生成的主键，二进制表示形式包含4部分，从高位到低位分表为：1bit符号位、41bit时间戳位、10bit工作进程位以及12bit序列号位。

符号位(1bit)
预留的符号位，恒为零。
时间戳位(41bit)
41位的时间戳可以容纳的毫秒数是2的41次幂，一年所使用的毫秒数是：365 * 24 * 60 * 60 * 1000。通过计算可知：

Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L);
结果约等于69.73年。ShardingSphere的雪花算法的时间纪元从2016年11月1日零点开始，可以使用到2086年，相信能满足绝大部分系统的要求。

工作进程位(10bit)
该标志在Java进程内是唯一的，如果是分布式应用部署应保证每个工作进程的id是不同的。该值默认为0，可通过调用静态方法DefaultKeyGenerator.setWorkerId()设置。
序列号位(12bit)
该序列是用来在同一个毫秒内生成不同的ID。如果在这个毫秒内生成的数量超过4096(2的12次幂)，那么生成器会等待到下个毫秒继续生成。

时钟回拨
服务器时钟回拨会导致产生重复序列，因此默认分布式主键生成器提供了一个最大容忍的时钟回拨毫秒数。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内，默认分布式主键生成器会等待时钟同步到最后一次主键生成的时间后再继续工作。最大容忍的时钟回拨毫秒数的默认值为0，可通过调用静态方法DefaultKeyGenerator.setMaxTolerateTimeDifferenceMilliseconds()设置。

强制分片路由

ShardingSphere使用ThreadLocal管理分片键值。可以通过编程的方式向HintManager中添加分片条件，该分片条件仅在当前线程内生效。

除了通过编程的方式使用强制分片路由，ShardingSphere还计划通过SQL中的特殊注释的方式引用Hint，使开发者可以采用更加透明的方式使用该功能。

指定了强制分片路由的SQL将会无视原有的分片逻辑，直接路由至指定的真实数据节点。

读写分离

目前仅支持单主库。可支持多从库。
核心功能

提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。
独立使用读写分离支持SQL透传。
同一线程且同一数据库连接内，如有写入操作，以后的读操作均从主库读取，用于保证数据一致性。
基于Hint的强制主库路由。

不支持项

主库和从库的数据同步。
主库和从库的数据同步延迟导致的数据不一致。
主库双写或多写。

数据治理使用Sharding-Proxy时待补充

Sharding-Proxy
提供注册中心、配置动态化、数据库熔断禁用、调用链路等治理能力。

支持的注册中心

SPI Service Provider Interface (SPI)是一种为了被第三方实现或扩展的API。它可以用于实现框架扩展或组件替换。
zookeeper 3.4.6及其以上版本（官方使用Apache Curator作为Zookeeper的实现方案）
https://www.cnblogs.com/seaspring/p/5536338.html
Etcd V3及其以上版本（开源的、分布式的键值对数据存储系统，提供共享配置、服务的注册和发现）
https://www.cnblogs.com/wuxun1997/p/8137753.html
其他使用SPI方式自行实现相关逻辑编码。

应用性能监控

APM是应用性能监控的缩写。
ShardingSphere并不负责如何采集、存储以及展示应用性能监控的相关数据，而是将SQL解析与SQL执行这两块数据分片的最核心的相关信息发送至应用性能监控系统，并交由其处理。

第一种方式是使用OpenTracing API发送性能追踪数据。面向OpenTracing协议的APM产品都可以和ShardingSphere自动对接，比如SkyWalking，Zipkin和Jaeger。使用这种方式只需要在启动时配置OpenTracing协议的实现者即可。它的优点是可以兼容所有的与OpenTracing协议兼容的产品作为APM的展现系统，如果采用公司愿意实现自己的APM系统，也只需要实现OpenTracing协议，即可自动展示ShardingSphere的链路追踪信息。缺点是OpenTracing协议发展并不稳定，较新的版本实现者较少，且协议本身过于中立，对于个性化的相关产品的实现不如原生支持强大。

第二种方式是使用SkyWalking的自动探针。 ShardingSphere团队与SkyWalking团队共同合作，在SkyWalking中实现了ShardingSphere自动探针，可以将相关的应用性能数据自动发送到SkyWalking中。
https://github.com/apache/skywalking/blob/5.x/docs/cn/Quick-start-CN.md

分布式事务

本地事务
XA强一致事务
柔性事务

	本地事务	两（三）阶段事务	柔性事务
业务改造	无	无	实现相关接口
一致性	不支持	支持	最终一致
隔离性	不支持	支持	业务方保证
并发性能	无影响	严重衰退	略微衰退
适合场景	业务方处理不一致	短事务 & 低并发	长事务 & 高并发

ShardingSphere支持将普通的数据库连接池，转换为支持XA事务的连接池，对HikariCP, Druid和DBCP2连接池内置支持，无需额外配置。

本地事务

完全支持非跨库事务，例如：仅分表，或分库但是路由的结果在单库中。
完全支持因逻辑异常导致的跨库事务。例如：同一事务中，跨两个库更新。更新完毕后，抛出空指针，则两个库的内容都能回滚。
不支持因网络、硬件异常导致的跨库事务。例如：同一事务中，跨两个库更新，更新完毕后、未提交之前，第一个库宕机，则只有第二个库数据提交。

两阶段事务

完全支持跨库事务。
默认使用Atomikos，支持使用SPI的方式加载其他XA事务管理器。

柔性事务（预计4.0.0支持）

完全支持跨库事务。
使用Servicecomb-Saga。
支持反向SQL以及更新快照自动生成以及自动补偿。

Atomikos、Servicecomb-Saga 待扩展

https://www.atomikos.com/Documentation/JtaProperties
https://www.breakyizhan.com/springboot/3413.html

使用与配置

Sharding-JDBC

定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

资料：
https://github.com/aalansehaiyang/technology-talk/blob/master/middle-software/sharding-jdbc.md

demo: https://github.com/AresKingCarry/ShardingJDBCDemo/tree/master/sharding-jdbc-demo-master
https://blog.csdn.net/kisscatforever/article/details/82746649

快速入门

pom.xml添加

<shardingsphere.version>3.1.0</shardingsphere.version>

<!-- shardingsphere -->
<dependency>
	<groupId>io.shardingsphere</groupId>
	<artifactId>sharding-jdbc-core</artifactId>
	<version>${shardingsphere.version}</version>
</dependency>

规则配置
Sharding-JDBC可以通过Java，YAML，Spring命名空间和Spring Boot Starter四种方式配置

创建DataSource

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

Spring Boot Starter 方式配置

https://gitee.com/xingbz/sharding-jdbc

当前集成使用的springboot版本2.0.6.RELEASE
原本DataSource配置删除
pom.xml中增加：

<sharding-sphere.version>3.1.0</sharding-sphere.version>

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

application.yml 中增加：

sharding:
  jdbc:
    # 数据源配置
    datasource:
      names: master-db1,master-db2,slave-db1,slave-db2
      master-db1:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/db1?useUnicode=true&characterEncoding=utf-8&useSSL=false
        username: root
        password: root
      slave-db1:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3309/db1?useUnicode=true&characterEncoding=utf-8&useSSL=false
        username: root
        password: root
      master-db2:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3306/db2?useUnicode=true&characterEncoding=utf-8&useSSL=false
        username: root
        password: root
      slave-db2:
        type: com.alibaba.druid.pool.DruidDataSource
        driver-class-name: com.mysql.jdbc.Driver
        url: jdbc:mysql://localhost:3309/db2?useUnicode=true&characterEncoding=utf-8&useSSL=false
        username: root
        password: root
    config:
      sharding:
        # 数据分片
        tables:
          t_order:
            actual-data-nodes: ds$->{0..1}.t_order_$->{0..1}
            table-strategy:
              # 行表达式分片策略
              inline:
                sharding-column: order_id
                algorithm-expression: t_order_$->{order_id % 2}
            key-generator-column-name: order_id
        # 绑定表规则列表
        binding-tables: t_order
        # 广播表规则列表
        broadcast-tables: t_user
        # 默认分库策略
        default-database-strategy:
          inline:
            sharding-column: user_id
            algorithm-expression: master-db$->{user_id % 2 + 1}
        # 读写分离
        master-slave-rules:
          ds0:
            master-data-source-name: master-db1
            slave-data-source-names: slave-db1
          ds1:
            master-data-source-name: master-db2
            slave-data-source-names: slave-db2
      props:
        # 是否开启SQL显示，默认值: false
        sql:
          show: true

SpringBoot 分布式事务配置

pom.xml增加：

<sharding-sphere.version>3.1.0</sharding-sphere.version>

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

启动类增加：（如果不加报错 io.shardingsphere.core.exception.ShardingException: Switching transaction Type is unsupported for transaction manager org.springframework.transaction.jta.JtaTransactionManager）

@SpringBootApplication(exclude = JtaAutoConfiguration.class)

service层使用：

@Override
@Transactional
@ShardingTransactionType(TransactionType.LOCAL)
//    @ShardingTransactionType(TransactionType.XA)
public boolean insertOrder(Order order) {
    orderMapper.insert(order);
    order.setUserId(4);
    orderMapper.insert(order);
    order.setUserId(5);
    testService.insertOrder2(order);
//        throw new RuntimeException("Exception occur for transaction test1.");
    return true;
}

Sharding-Proxy

定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前先提供MySQL版本，它可以使用任何兼容MySQL协议的访问客户端(如：MySQL Command Client, MySQL Workbench等)操作数据，对DBA更加友好。

快速入门

规则配置
编辑%SHARDING_PROXY_HOME%\conf\config-xxx.yaml。详情请参见配置手册。

编辑%SHARDING_PROXY_HOME%\conf\server.yaml。详情请参见配置手册。

启动服务
使用默认配置项
${sharding-proxy}\bin\start.sh ${port}
配置端口
${sharding-proxy}\bin\start.sh ${port}

Sharding-Sidecar（TBD）

腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

腾讯云开发者社区

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

腾讯云开发者社区

所有评论(0)

查看更多评论

hanyue99s

@hanyue99s

已为社区贡献4条内容

Sharding-Sphere的分享

hanyue99s

文章目录

概念 & 功能

数据分片

SQL

分片

配置

内核剖析

解析引擎

路由引擎

改写引擎

执行引擎

归并引擎

使用规范

SQL

分页

其他功能

行表达式

分布式主键

强制分片路由

读写分离

数据治理 使用Sharding-Proxy时待补充

支持的注册中心

应用性能监控

分布式事务

本地事务

两阶段事务

柔性事务（预计4.0.0支持）

Atomikos、Servicecomb-Saga 待扩展

使用与配置

Sharding-JDBC

快速入门

Spring Boot Starter 方式配置

SpringBoot 分布式事务配置

Sharding-Proxy

快速入门

Sharding-Sidecar（TBD）

所有评论(0)

温馨提示：您尚未绑定手机号

hanyue99s

数据治理使用Sharding-Proxy时待补充