1 分库分表实战

1.1 背景

刚开始我们的系统只用了单机数据库

随着用户的不断增多，考虑到系统的高可用和越来越多的用户请求，我们开始使用数据库主从架构

当用户量级和业务进一步提升后，写请求越来越多，这时我们开始使用了分库分表

1.2 遇到的问题

• 用户请求量太大
  单服务器TPS、内存、IO都是有上限的，需要将请求打散分布到多个服务器

• 单库数据量太大
  单个数据库处理能力有限；单库所在服务器的磁盘空间有限；单库上的操作IO有瓶颈

• 单表数据量太大
  查询、插入、更新操作都会变慢，再加字段、加索引、机器迁移都会产生高负载，影响服务

1.3 如何解决

垂直拆分

垂直分库 微服务架构时，业务切割得足够独立，数据也会按照业务切分，保证业务数据隔离，大大提 升了数据库的吞吐能力

垂直分表 表中字段太多且包含大字段的时候，在查询时对数据库的IO、内存会受到影响，同时更新数 据时，产生的binlog文件会很大，MySQL在主从同步时也会有延迟的风险

水平拆分

水平分表 针对数据量巨大的单张表（比如订单表），按照规则把一张表的数据切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。

水平分库 将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合 不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件 资源等的瓶颈

水平分库规则

使用的时候需要注意：

不跨库、不跨表，保证同一类的数据都在同一个服务器上面。

数据在切分之前，需要考虑如何高效的进行数据获取，如果每次查询都要跨越多个节点，就需要谨慎使用。

水平分表规则

• RANGE

  • 时间：按照年、月、日去切分。例如order_2020、order_202005、order_20200501

  • 地域：按照省或市去切分。例如order_beijing、order_shanghai、order_chengdu

  • 大小：从0到1000000一个表。例如1000001-2000000放一个表，每100万放一个表

• Hash （根据实际业务情况采用适合的hash算法）

  • 用户id取模
    不同的业务使用的切分规则是不一样，就上面提到的切分规则
    比如：

    站内信：

①用户维度：用户只能看到发送给自己的消息，其他用户是不可见的，这种情况下是按照 用户ID hash分库，在用户查看历史记录翻页查询时，所有的查询请求都在同一个库内

用户表：以用户ID为划分依据，将数据水平切分到两个数据库实例，

① 范围法：如：1到1000W在 一张表，1000W到2000W在一张表，这种情况会出现单表的负载较高

② 按照用户ID HASH尽量保证用户数据均衡分到数据库中

如果在登录场景下，用户输入手机号和验证码进行登录，这种情况下，登录时是不是需要扫描所有分库的信息？

最终方案：用户信息采用ID做切分处理，同时存储用户ID和手机号的映射的关系 表（新增一个关系表），关系表采用手机号进行切分。可以通过关系表根据手机号查询到对应的ID，再定位用户信息。

流水表：

① 时间维度：可以根据每天新增的流水来判断，选择按照年份分库，还是按照月份分库， 甚至也可以按照日期分库

订单表 ：

在拉勾网，求职者（下面统称C端用户）投递企业（下面统称B端用户）的职位产生的记录称 之为订单表。在线上的业务场景中，C端用户看自己的投递记录，每次的投递到了哪个状态， B端用户查看自己收到的简历，对于合适的简历会进行下一步沟通，同一个公司内的员工可以 协作处理简历。

如何能同时满足C端和B端对数据查询，不进行跨库处理？

最终方案：为了同时满足两端用户的业务场景，采用空间换时间，将一次的投递记录存为两 份，C端的投递记录以用户ID为分片键，B端收到的简历按照公司ID为分片键

• 主键选择
  UUID：本地生成，不依赖数据库，缺点就是作为主键性能太差
  SNOWFLAKE：百度UidGenerator、美团Leaf、基于SNOWFLAKE算法实现

• 数据一致性
  强一致性：XA协议
  最终一致性：TCC、saga、Seata

• 数据库扩容
  成倍增加数据节点，实现平滑扩容
  成倍扩容以后，表中的部分数据请求已被路由到其他节点上面，可以清理掉

• 业务层改造
  基于代理层方式：Mycat、Sharding-Proxy、MySQL Proxy
  基于应用层方式：Sharding-jdbc

• 分库后面临的问题
  事务问题：一次投递需要插入两条记录，且分布在不同的服务器上，数据需要保障一致性。
  跨库表的join问题：

  全局表（字典表）：基础数据/配置数据，所有库都拷贝一份

字段冗余：可以使用字段冗余就不用join查询了

系统层组装：可以在业务层分别查询出来，然后组装起来，逻辑较复杂

额外的数据管理负担和数据运算压力：数据库扩容、维护成本变高

2 ShardingSphere

对于 5.0版本是一个大版本的迭代，改动很大。

2.1 概念

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三者区别如下：

2.2 ShardingJdbc

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

• 数据分片
  分库、分表
  读写分离
  分片策略
  分布式主键

• 分布式事务
  标准化的事务接口 Local
  XA强一致性事务 XA
  柔性事务 BASE

• 数据库治理
  配置动态化
  编排和治理
  数据脱敏
  可视化链路追踪

2.3 ShardingJdbc 内部结构

各组件及其功能

• 图中黄色部分表示的是Sharding-JDBC的入口API，采用工厂方法的形式提供。 目前有 ShardingDataSourceFactory和MasterSlaveDataSourceFactory两个工厂类。

  • ShardingDataSourceFactory支持分库分表、读写分离操作 这个需要同时配置在 ShardingRuleConfiguration中同时配置 TableRuleConfiguration和MasterSlaveConfiguaration了。因为我们分出来的节点可能会对应有从库，读操作需要从从库进行读取 。

  • MasterSlaveDataSourceFactory支持读写分离操作

• 图中蓝色部分表示的是Sharding-JDBC的配置对象，提供灵活多变的配置方式。 ShardingRuleConfiguration是分库分表配置的核心和入口，它可以包含多个 TableRuleConfiguration和MasterSlaveRuleConfiguration。

  • TableRuleConfiguration封装的是表的分片配置信息，有5种配置形式对应不同的 Configuration类型。
  • MasterSlaveRuleConfiguration封装的是读写分离配置信息。
• 图中红色部分表示的是内部对象，由Sharding-JDBC内部使用，应用开发者无需关注。ShardingJDBC通过ShardingRuleConfiguration和MasterSlaveRuleConfiguration生成真正供 ShardingDataSource和MasterSlaveDataSource使用的规则对象。ShardingDataSource和 MasterSlaveDataSource实现了DataSource接口，是JDBC的完整实现方案。

Sharding-JDBC初始化流程

• 根据配置的信息生成Configuration对象
• 通过Factory会将Configuration对象转化为Rule对象
• 通过Factory会将Rule对象与DataSource对象封装
• Sharding-JDBC使用DataSource进行分库分表和读写分离操作

2.4 使用流程

1，引入依赖

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>sharding-jdbc-core</artifactId>
</dependency>

2，规则配置

Sharding-JDBC可以通过Java，YAML，Spring命名空间和Spring Boot Starter四种方式配置，开 发者可根据场景选择适合的配置方式。

3，创建DataSource

通过ShardingDataSourceFactory工厂和规则配置对象获取ShardingDataSource，然后即可通过 DataSource选择使用原生JDBC开发，或者使用JPA, MyBatis等ORM工具。

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

4 数据分片实战

4.1 数据分片核心概念

表概念

真实表：数据库中真实存在的物理表。例如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);

比如10在b_order0里面，11在b_order1里面

如果不配置绑定表关系，采用笛卡尔积关联，会生成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);

广播表：在使用中，有些表没必要做分片，例如字典表、省份信息等，因为他们数据量不大，而且这 种表可能需要与海量数据的表进行关联查询。广播表会在不同的数据节点上进行存储，存储 的表结构和数据完全相同。

分片算法 ShardingAlgorithm

由于分片算法和业务实现紧密相关，因此并未提供内置分片算法，而是通过分片策略将各种场景提 炼出来，提供更高层级的抽象，并提供接口让应用开发者自行实现分片算法。目前提供4种分片算 法。

• 精确分片算法PreciseShardingAlgorithm 用于处理使用单一键作为分片键的=与IN进行分片的场景。
• 范围分片算法 RangeShardingAlgorithm 用于处理使用单一键作为分片键的BETWEEN AND、>、<、>=、<=进行分片的场景。
• 复合分片算法ComplexKeysShardingAlgorithm 用于处理使用多键作为分片键进行分片的场景，多个分片键的逻辑较复杂，需要应用开发者自行处理其中的复杂度。
• Hint分片算法HintShardingAlgorithm 用于处理使用Hint行分片的场景。对于分片字段非SQL决定，而由其他外置条件决定的场景，可使用SQL Hint灵活的注入分片字段。例：内部系统，按照员工登录主键分库，而数据 库中并无此字段。SQL Hint支持通过Java API和SQL注释两种方式使用。

分片策略 ShardingStrategy

分片策略包含分片键和分片算法，真正可用于分片操作的是分片键 + 分片算法，也就是分片策 略。目前提供5种分片策略。

• 标准分片策略StandardShardingStrategy 只支持单分片键，提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。
  提供PreciseShardingAlgorithm和RangeShardingAlgorithm两个分片算法。 PreciseShardingAlgorithm是必选的，RangeShardingAlgorithm是可选的。但是SQL中使用 了范围操作，如果不配置RangeShardingAlgorithm会采用全库路由扫描，效率低。

• 复合分片策略ComplexShardingStrategy
  支持多分片键。提供对SQL语句中的=, >, <, >=, <=, IN和BETWEEN AND的分片操作支持。由 于多分片键之间的关系复杂，因此并未进行过多的封装，而是直接将分片键值组合以及分片 操作符透传至分片算法，完全由应用开发者实现，提供最大的灵活度

• 行表达式分片策略InlineShardingStrategy
  只支持单分片键。使用Groovy的表达式，提供对SQL语句中的=和IN的分片操作支持，对于简单的分片算法，可以通过简单的配置使用，从而避免繁琐的Java代码开发。如: tuser$-> {u_id % 8} 表示t_user表根据u_id模8，而分成8张表，表名称为t_user_0到t_user_7。

• Hint分片策略HintShardingStrategy
  通过Hint指定分片值而非从SQL中提取分片值的方式进行分片的策略。

• 不分片策略NoneShardingStrategy
  不分片的策略。

分片策略配置：

对于分片策略存有数据源分片策略和表分片策略两种维度，两种策略的API完全相同。

• 数据源分片策略 用于配置数据被分配的目标数据源。

• 表分片策略用于配置数据被分配的目标表，由于表存在与数据源内，所以表分片策略是依赖数据源分片策略结果的。

4.2 数据分片流程剖析

执行流程：

• SQL解析 SQL解析分为词法解析和语法解析。
  先通过词法解析器将SQL拆分为一个个不可再分的单词。再使 用语法解析器对SQL进行理解，并最终提炼出解析上下文。
  Sharding-JDBC采用不同的解析器对SQL进行解析，解析器类型如下：

  • MySQL解析器

  • Oracle解析器

  • SQLServer解析器

  • PostgreSQL解析器

  • 默认SQL解析器 （比如db2，seadb可以使用）

• 查询优化
  负责合并和优化分片条件，如OR等。Mysql也有自己的查询优化器。如果or的条件有索引，通常会拆分为union

• SQL路由
  根据解析上下文匹配用户配置的分片策略，并生成路由路径。目前支持分片路由和广播路由。

• SQL改写
  将SQL改写为在真实数据库中可以正确执行的语句。SQL改写分为正确性改写和优化改写。

• SQL执行
  通过多线程执行器异步执行SQL。

• 结果归并
  将多个执行结果集归并以便于通过统一的JDBC接口输出。结果归并包括流式归并、内存归并和使用装饰者模式的追加归并这几种方式。

解析->优化->路由->改写->执行->合并结果

4.3 Sql使用规范

支持项：

①路由至单数据节点时，目前MySQL数据库100%全兼容，其他数据库完善中。 路由至多数据节点时，全面支持DQL、DML、DDL、DCL、TCL。支持分页、去重、排 序、分组、聚合、关联查询（不支持跨库关联）。以下用最为复杂的查询为例：

SELECT select_expr [, select_expr ...]
FROM table_reference [, table_reference ...]
[WHERE predicates]
[GROUP BY {col_name | position} [ASC | DESC], ...]
[ORDER BY {col_name | position} [ASC | DESC], ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]

不支持项：

②支持分页子查询，但其他子查询有限支持，无论嵌套多少层，只能解析至第一个包含数据表 的子查询，一旦在下层嵌套中再次找到包含数据表的子查询将直接抛出解析异常。

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

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无法提前获取分片键位于数据库中的值，从而无法计算出真正 的分片值。

不支持的SQL示例：

INSERT INTO tbl_name (col1, col2, …) VALUES(1+2, ?, …) #VALUES语句不支持运算表达式
INSERT INTO tbl_name (col1, col2, …) SELECT col1, col2, … FROM tbl_name
WHERE col3 = ? #INSERT .. SELECT
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 ds.tbl_name1 #包含schema
SELECT SUM(DISTINCT col1), SUM(col1) FROM tbl_name #同时使用普通聚合函数和DISTINCT
SELECT * FROM tbl_name WHERE to_date(create_time, ‘yyyy-mm-dd’) = ? #会导致全路由

4.4 分页查询

完全支持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个方面的优化。
①采用流式处理 + 归并排序的方式来避免内存的过量占用。
②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

但是我们的id不一定是连续的可能中间删除了：

select * from u_user where id>(select id from u_user limit 10000,1) limit 10

4.5 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_order1
 └── b_order2

可以简化为：

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}

sharding-jdbc 实现了DataSource,Connection,Statement,PrepareStatemnt,ResultSet。

相当于对原来连接池DataSource,Connection,Statement,PrepareStatemnt,ResultSet基础上的封装。

最后crud工作还是要交给原始的Statement去处理。

sharding-jdbc 的自动配置类为SpringBootConfiguration。会向容器中注入DataSource和事务注解扫描器ShardingTransactionTypeScanner。

@Bean
    @Conditional(ShardingRuleCondition.class)
    public DataSource shardingDataSource() throws SQLException {
        return ShardingDataSourceFactory.createDataSource(dataSourceMap, new ShardingRuleConfigurationYamlSwapper().swap(shardingRule), props.getProps());
    }
    /**
     * Get master-slave data source bean.
     *
     * @return data source bean
     * @throws SQLException SQL exception
     */
    @Bean
    @Conditional(MasterSlaveRuleCondition.class)
    public DataSource masterSlaveDataSource() throws SQLException {
        return MasterSlaveDataSourceFactory.createDataSource(dataSourceMap, new MasterSlaveRuleConfigurationYamlSwapper().swap(masterSlaveRule), props.getProps());
    }
    /**
     * Get encrypt data source bean.
     *
     * @return data source bean
     * @throws SQLException SQL exception
     */
    @Bean
    @Conditional(EncryptRuleCondition.class)
    public DataSource encryptDataSource() throws SQLException {
        return EncryptDataSourceFactory.createDataSource(dataSourceMap.values().iterator().next(), new EncryptRuleConfigurationYamlSwapper().swap(encryptRule), props.getProps());
    }
    /**
     * Get shadow data source bean.
     *
     * @return data source bean
     * @throws SQLException SQL exception
     */
    @Bean
    @Conditional(ShadowRuleCondition.class)
    public DataSource shadowDataSource() throws SQLException {
        return ShadowDataSourceFactory.createDataSource(dataSourceMap, new ShadowRuleConfigurationYamlSwapper().swap(shadowRule), props.getProps());
    }
    /**
     * Create sharding transaction type scanner.
     *
     * @return sharding transaction type scanner
     */
    @Bean
    public ShardingTransactionTypeScanner shardingTransactionTypeScanner() {
        return new ShardingTransactionTypeScanner();
    }

有四种DataSource，但是根据条件判断，只能生成一种DataSource。如果你的配置文件使满足多种，是会报错的。

public final class ShardingRuleCondition extends SpringBootCondition {
    @Override
    public ConditionOutcome getMatchOutcome(final ConditionContext conditionContext, final AnnotatedTypeMetadata annotatedTypeMetadata) {
        boolean isMasterSlaveRule = new MasterSlaveRuleCondition().getMatchOutcome(conditionContext, annotatedTypeMetadata).isMatch();
        boolean isEncryptRule = new EncryptRuleCondition().getMatchOutcome(conditionContext, annotatedTypeMetadata).isMatch();
        boolean isShadow = new ShadowRuleCondition().getMatchOutcome(conditionContext, annotatedTypeMetadata).isMatch();
        return isMasterSlaveRule || isEncryptRule || isShadow ? ConditionOutcome.noMatch("Have found master-slave or encrypt rule in environment") : ConditionOutcome.match();
    }
}

如果配置有MasterSlaveRule、EncryptRule、Shadow那就说明不会注入ShardingDataSource。

4.6 主键生成原理

ShardingSphere不仅提供了内置的分布式主键生成器，例如UUID、SNOWFLAKE。

当然还可以实现为org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator接口自定义主键生成器。

内置主键生成器： UUID 采用UUID.randomUUID()的方式产生分布式主键。

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.keygenerator.type=LAGOUKEY

5 ShardingJdbc实战

工共的配置：ConfigurationPropertyKey

5.1 分库，分库分表

注意点：

• 广播表不能使用配置的默认的主键生成策略，要单独配置

  • 当我们使用sharding-jdbc提供的主键生生策略的时候，需要将主键生成策略应该配置成 @GeneratedValue(strategy = GenerationType.IDENTITY)。
• 关联表不能跨库，我试了下将这个pid放到和主表不同的库会查不出来detail的信息的

配置文件：

application.yml配置文件

spring:
  jpa:
    show-sql: true
    database: mysql
    hibernate:
      naming:
        #比如BusinessOrder转成business_order liveCity转成live_city
        physical-strategy: org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy
        implicit-strategy: org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
  profiles:
    active: sharding-jdbc

application-sharding-jdbc.properties配置文件

#打印sql
spring.shardingsphere.props.sql.show=true
#datasource
spring.shardingsphere.datasource.names=ds0,ds1
#数据库连接池类型
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds1.type=com.zaxxer.hikari.HikariDataSource
#连接信息
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://localhost:3306/order0?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root
spring.shardingsphere.datasource.ds1.jdbc-url=jdbc:mysql://localhost:3306/order1?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=root
#sharding database
#指定分片键
spring.shardingsphere.sharding.tables.position.database-strategy.inline.sharding-column=id
#分片表达式
spring.shardingsphere.sharding.tables.position.database-strategy.inline.algorithm-expression=ds${id%2}
#指定分片键
spring.shardingsphere.sharding.tables.position_detail.database-strategy.inline.sharding-column=pid
#分片表达式
spring.shardingsphere.sharding.tables.position_detail.database-strategy.inline.algorithm-expression=ds${pid%2}
#指定默认id生成策略
spring.shardingsphere.sharding.default-key-generator.column=id
spring.shardingsphere.sharding.default-key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.default-key-generator.props.worker.id=1
spring.shardingsphere.sharding.default-key-generator.props.max.vibration.offset=2
#指定表id生成策略
spring.shardingsphere.sharding.tables.position.key-generator.column=id
spring.shardingsphere.sharding.tables.position.key-generator.type=SNOWFLAKE
#算法属性 可以看没课策略里面可以配置的属性
spring.shardingsphere.sharding.tables.position.key-generator.props.worker.id=2
spring.shardingsphere.sharding.tables.position.key-generator.props.max.vibration.offset=3
#配置广播表
#多个用逗号隔开
spring.shardingsphere.sharding.broadcast-tables=city
spring.shardingsphere.sharding.tables.city.key-generator.column=id
spring.shardingsphere.sharding.tables.city.key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.tables.city.key-generator.props.worker.id=2
spring.shardingsphere.sharding.tables.city.key-generator.props.max.vibration.offset=3
#即分库又分表
#根据company_id分库
spring.shardingsphere.sharding.tables.b_order.database-strategy.inline.sharding-column=company_id
spring.shardingsphere.sharding.tables.b_order.database-strategy.inline.algorithm-expression=ds${company_id%2}
#按照id分表
spring.shardingsphere.sharding.tables.b_order.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.b_order.table-strategy.inline.algorithm-expression=b_order${id%2}
spring.shardingsphere.sharding.tables.b_order.actual-data-nodes=ds${0..1}.b_order${0..1}

测试类：

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ShardingJdbcApp.class)
public class ShardingJdbcTest {
    @Autowired
    private PositionRepository positionRepository;
    @Autowired
    private PositionDetailRepository positionDetailRepository;
    @Autowired
    private CityRepository cityRepository;
    @Autowired
    private BOrderRepository bOrderRepository;
    @Test
    public void addPosition1() {
        int len = 20;
        List<Position> positions = new ArrayList<>(len);
        Position position;
        for (long i = len; i > 1; i--) {
            position = new Position();
            position.setId(i);
            position.setName("稻壳儿");
            position.setSalary("19999");
            position.setLiveCity("东莞");
            positions.add(position);
        }
        positionRepository.saveAll(positions);
    }
    @Test
    //雪花算法生成id
    public void addPosition2() {
        int len = 10;
        List<Position> positions = new ArrayList<>(len);
        Position position;
        for (long i = len; i > 1; i--) {
            position = new Position();
            position.setName("花生壳儿");
            position.setSalary("29999");
            position.setLiveCity("北京");
            positions.add(position);
        }
        positionRepository.saveAll(positions);
    }
    @Test
    public void addPositionDetail1(){
        int len = 10;
        //注意主键生成策略应该配置成 @GeneratedValue(strategy = GenerationType.IDENTITY)
        List<PositionDetail> positionDetails = new ArrayList<>();
        PositionDetail positionDetail;
        for (long i = 1; i < len; i++) {
            positionDetail = new PositionDetail();
            positionDetail.setId(i);
            positionDetail.setPid(2l);
            positionDetail.setDescription("稻壳儿描述信息");
            positionDetails.add(positionDetail);
        }
        positionDetailRepository.saveAll(positionDetails);
    }
    @Test
    public void addPositionAndDetail1(){
        int len = 10;
        Position position;
        PositionDetail positionDetail;
        for (long i = len; i > 1; i--) {
            position = new Position();
            position.setName("花生壳儿");
            position.setSalary("29999");
            position.setLiveCity("北京");
            positionRepository.save(position);
            positionDetail = new PositionDetail();
            positionDetail.setPid(position.getId());
            positionDetail.setDescription("这是备注信息");
            positionDetailRepository.save(positionDetail);
        }
    }
    @Test
    public void findByIdJoin(){
        //关联表不能跨库，我试了下将这个pid放到和主表不同的库会查不出来detail的信息的
        Object position = positionRepository.getById(510152504277737472l);
        Object[] objects = (Object[])position;
        System.out.println(Arrays.toString(objects));
    }
    @Test
    public void addBroadcastTableValue(){
        //city为广播表，会向每个库都插入数据
        //广播表不能使用配置的默认的主键生成策略，要单独配置
        City city = new City();
        city.setName("东莞");
        city.setProvince("广东");
        cityRepository.save(city);
    }
    @Test
    //根据company_id分库 id在同一个库进行分表
    public void addBOrder(){
        int len = 100;
        BOrder bOrder;
        for (int i = 0; i < len; i++) {
            bOrder = new BOrder();
            bOrder.setCompanyId(i);
            bOrder.setUserId(3242);
            bOrder.setDel(false);
            bOrder.setCreateTime(LocalDateTime.now());
            bOrder.setOperateTime(LocalDateTime.now());
            bOrder.setName("不加葱");
            bOrder.setPositionId(2345l);
            bOrder.setPositionName("java高级");
            bOrder.setPublishUserId(239002);
            bOrder.setResumeId(98823);
            bOrder.setResumeType(1);
            bOrder.setStatus("AUTO_FILTER");
            bOrder.setWorkYear("3年");
            bOrderRepository.save(bOrder);
        }
    }
    @Test
    public void getBOrderById(){
        //因为没有指定companyId所以没法确定属于那个库的数据，路由到ds0,ds1都去查询一次
        Optional<BOrder> byId = bOrderRepository.findById(510503386764808193l);
        System.out.println(byId.get());
    }
    @Test
    public void getBOrderByIdAncCompanyId(){
        //指定id 和companyId会锁定唯一库和唯一分片
        BOrder result = bOrderRepository.findByIdAndCompanyId(510503386764808193l,4);
        System.out.println(result);
    }
}

BOrder实体

@Entity(name = "b_order")
public class BOrder {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;
    private Boolean isDel;
    private Integer companyId;
    private long positionId;
    private Integer userId;
    private Integer publishUserId;
    private Integer resumeType;
    private String status;
    private LocalDateTime createTime;
    private LocalDateTime operateTime;
    private String workYear;
    private String name;
    private String positionName;
    private Integer resumeId;
  }

City实体

@Entity
public class City implements java.io.Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String province;
}

Position实体

@Entity
public class Position implements Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String salary;
    private String liveCity;
  }

PositionDetail实体

@Entity
public class PositionDetail implements java.io.Serializable{
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long pid;
    private String description;
 }

5.2 读写分离

主从架构：读写分离，目的是高可用、读写扩展。主从库内容相同，根据SQL语义进行路由。

分库分表架构：数据分片，目的读写扩展、存储扩容。库和表内容不同，根据分片配置进行路由。

将水平分片和读写分离联合使用，能够更加有效的提升系统性能

下图展现了将分库分表与读写分离一 同使用时，应用程序与数据库集群之间的复杂拓扑关系。

读写分离虽然可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题，包括多个主库之间 的数据一致性，以及主库与从库之间的数据一致性的问题。 并且，读写分离也带来了与数据分片同样的 问题，它同样会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。

透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 ShardingSphere读写分离模块的主要设计目标。

• 核心功能
  提供一主多从的读写分离配置。仅支持单主库，可以支持独立使用，也可以配合分库分表使用
  独立使用读写分离，支持SQL透传。不需要SQL改写流程 同一线程且同一数据库连接内，能保证数据一致性。如果有写入操作，后续的读操作均从主 库读取。
  基于Hint的强制主库路由。可以强制路由走主库查询实时数据，避免主从同步数据延迟。

• 不支持项
  主库和从库的数据同步
  主库和从库的数据同步延迟
  主库双写或多写
  跨主库和从库之间的事务的数据不一致。建议在主从架构中，事务中的读写均用主库操作。

配置文件：

application.yml

spring:
  jpa:
    show-sql: true
    database: mysql
    hibernate:
      naming:
        physical-strategy: org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy
        implicit-strategy: org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
  profiles:
    active: master-slave

application-master-slave.properties

#打印sql
spring.shardingsphere.props.sql.show=true
#datasource
spring.shardingsphere.datasource.names=master,slave0
#数据库连接池类型
spring.shardingsphere.datasource.master.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave0.type=com.zaxxer.hikari.HikariDataSource
#连接信息
spring.shardingsphere.datasource.master.jdbc-url=jdbc:mysql://localhost:3306/order0?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.master.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.master.username=root
spring.shardingsphere.datasource.master.password=root
spring.shardingsphere.datasource.slave0.jdbc-url=jdbc:mysql://localhost:3306/order1?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.slave0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.slave0.username=root
spring.shardingsphere.datasource.slave0.password=root
#简单主从配置 只有主从库，没有主库分片
#主库名字
spring.shardingsphere.masterslave.master-data-source-name=master
#从库名字
spring.shardingsphere.masterslave.slave-data-source-names=slave0
#数据源的名字 可以随便指定一个
spring.shardingsphere.masterslave.name=datasource
#从库负载均衡算法类型 RANDOM,ROUND_ROBIN  MasterSlaveLoadBalanceAlgorithm可以利用spi机制自己实现
#只会对从库进行负载均衡
spring.shardingsphere.masterslave.load-balance-algorithm-type=RANDOM

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ShardingJdbcApp.class)
public class MasterSlaveTest {
    @Autowired
    private PositionRepository positionRepository;
    @Test
    public void addPosition(){
        Position position = new Position();
        position.setLiveCity("东莞");
        position.setSalary("199999");
        position.setName("Java高级开发");
        positionRepository.save(position);
    }
    @Test
    public void find(){
        List<Position> all = positionRepository.findAll();
        all.stream().forEach(System.out::println);
    }
    @Test
    @Transactional
    public void insertAndFind(){
        Position position = new Position();
        position.setLiveCity("东莞");
        position.setSalary("199999");
        position.setName("Java高级开发");
        positionRepository.save(position);
        List<Position> all = positionRepository.findAll();
        all.stream().forEach(System.out::println);
    }
}

我这里没有实际搭建主从库，是用两个库来模拟的。插入数据确实是往master库添加的，读取数据是从库读取的。不过如果同一个事务内既有增删改操作又有查询操作，走的都是主库。

5.3 设计升级过程

读写分离应用方案

在数据量不是很多的情况下，我们可以将数据库进行读写分离，以应对高并发的需求，通过水平扩展从库，来缓解查询的压力。

分表+读写分离

在数据量达到500万的时候，这时数据量预估千万级别，我们可以将数据进行分表存储。

分库分表+读写分离

在数据量继续扩大，这时可以考虑分库分表，将数据存储在不同数据库的不同表中。

这个配置相对于前面的单独的读写分离有一些复杂

application-sharding-master-slave.properties

#数据源
spring.shardingsphere.datasource.names=master0,slave0,slave1,master1,slave2,slave3
spring.shardingsphere.datasource.master0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.master0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master0.jdbc-url=jdbc:mysql://localhost:3306/master0?useUnicode=true&characterEncoding=utf-8&useSSL=false
spring.shardingsphere.datasource.master0.username=root
spring.shardingsphere.datasource.master0.password=root
spring.shardingsphere.datasource.slave0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave0.jdbc-url=jdbc:mysql://localhost:3306/slave0?useSSL=false
spring.shardingsphere.datasource.slave0.username=root
spring.shardingsphere.datasource.slave0.password=root
spring.shardingsphere.datasource.slave1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave1.jdbc-url=jdbc:mysql://localhost:3306/slave1?useSSL=false
spring.shardingsphere.datasource.slave1.username=root
spring.shardingsphere.datasource.slave1.password=root
spring.shardingsphere.datasource.master1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.master1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master1.jdbc-url=jdbc:mysql://localhost:3306/master1?useUnicode=true&characterEncoding=utf-8&useSSL=false
spring.shardingsphere.datasource.master1.username=root
spring.shardingsphere.datasource.master1.password=root
spring.shardingsphere.datasource.slave2.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave2.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave2.jdbc-url=jdbc:mysql://localhost:3306/slave2?useSSL=false
spring.shardingsphere.datasource.slave2.username=root
spring.shardingsphere.datasource.slave2.password=root
spring.shardingsphere.datasource.slave3.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave3.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave3.jdbc-url=jdbc:mysql://localhost:3306/slave3?useSSL=false
spring.shardingsphere.datasource.slave3.username=root
spring.shardingsphere.datasource.slave3.password=root
#分库分表
spring.shardingsphere.sharding.tables.b_order.database-strategy.inline.sharding-column=company_id
spring.shardingsphere.sharding.tables.b_order.database-strategy.inline.algorithm-expression=master$->{company_id % 2}
spring.shardingsphere.sharding.tables.b_order.actual-data-nodes=master$->{0..1}.b_order$->{0..1}
spring.shardingsphere.sharding.tables.b_order.table-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.b_order.table-strategy.inline.algorithm-expression=b_order$->{id % 2}
#读写分离
#主库分片一
spring.shardingsphere.sharding.master-slave-rules.master0.master-data-source-name=master0
#主库分片一的从库
spring.shardingsphere.sharding.master-slave-rules.master0.slave-data-source-names=slave0,slave1
#从库负载均衡算法
spring.shardingsphere.sharding.master-slave-rules.master0.load-balance-algorithm-type=RANDOM
#主库分片二
spring.shardingsphere.sharding.master-slave-rules.master1.master-data-source-name=master1
#主库分片二的从库
spring.shardingsphere.sharding.master-slave-rules.master1.slave-data-source-names=slave2,slave3
#从库负载均衡算法
spring.shardingsphere.sharding.master-slave-rules.master1.load-balance-algorithm-type=RANDOM

5.4 强制路由

配置文件

注意：一个逻辑表不能配置多种sharding-strategy不然启动会报错

application-sharding-hint.properties

#打印sql
spring.shardingsphere.props.sql.show=true
#datasource
spring.shardingsphere.datasource.names=ds0,ds1
#数据库连接池类型
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds1.type=com.zaxxer.hikari.HikariDataSource
#连接信息
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://localhost:3306/order0?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root
spring.shardingsphere.datasource.ds1.jdbc-url=jdbc:mysql://localhost:3306/order1?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=root
#分库策略
#hint只用指定策略，不用再指定列表，以及表达式了
spring.shardingsphere.sharding.tables.position.database-strategy.hint.algorithm-class-name=com.wh.learn.algorithm.CustomHintStrategy
#指定默认id生成策略
spring.shardingsphere.sharding.default-key-generator.column=id
spring.shardingsphere.sharding.default-key-generator.type=SNOWFLAKE
spring.shardingsphere.sharding.default-key-generator.props.worker.id=1
spring.shardingsphere.sharding.default-key-generator.props.max.vibration.offset=2

自定义的hint的路由策略

public class CustomHintStrategy implements HintShardingAlgorithm<Long> {
    @Override
    public Collection<String> doSharding(Collection<String> collection, HintShardingValue<Long> hintShardingValue) {
        //collection参数为配置的 datasource名称 spring.shardingsphere.datasource.names=ds0,ds1
        //HintShardingValue 有三个值logicTableName逻辑表明
        //columnName列明 这个是空的
        //values 为HintManager中设置的值,,正常来说我们需要根据value值来进行库的选择
        //如果返回多个，那么多个库都会写入数据
        //我这里的所有的都用第一个
        String first  = null;
        for (String s : collection) {
            first = s;
            break;
        }
        return Arrays.asList(first);
    }
}

测试类

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ShardingJdbcApp.class)
public class HintShardingStrategyTest {
    @Autowired
    private PositionRepository positionRepository;
    @Test
    public void addPosition(){
        HintManager hintManager = HintManager.getInstance();
        //如果这里不设置值，就会全路由，在所有分片表中写入数据
        //addTableShardingValue(logicTable,value)这个方法设置的值无效
        hintManager.setDatabaseShardingValue(2L);
        Position position = new Position();
        position.setLiveCity("广州");
        position.setSalary("399999");
        position.setName("java架构");
        positionRepository.save(position);
        hintManager.close();
    }
    @Test
    public void find(){
        HintManager hintManager = HintManager.getInstance();
        hintManager.setDatabaseShardingValue(2L);
        List<Position> all = positionRepository.findAll();
        all.stream().forEach(System.out::println);
    }
}

在读写分离结构中，为了避免主从同步数据延迟及时获取刚添加或更新的数据，可以采用强制路由走主库查询实时数据，使用hintManager.setMasterRouteOnly设置主库路由即可。

5.5 数据脱敏剖析

数据脱敏是指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。涉及客户 安全数据或者一些商业性敏感数据，如身份证号、手机号、卡号、客户号等个人信息按照规定，都需要 进行数据脱敏。

数据脱敏模块属于ShardingSphere分布式治理这一核心功能下的子功能模块。

• 在更新操作时，它通过对用户输入的SQL进行解析，并依据用户提供的脱敏配置对SQL进行改写， 从而实现对原文数据进行加密，并将密文数据存储到底层数据库。
• 在查询数据时，它又从数据库中取出密文数据，并对其解密，最终将解密后的原始数据返回给用 户。

Apache ShardingSphere自动化&透明化了数据脱敏过程，让用户无需关注数据脱敏的实现细节，像使用普通数据那样使用脱敏数据。

整体架构

ShardingSphere提供的Encrypt-JDBC和业务代码部署在一起。业务方需面向Encrypt-JDBC进行JDBC编 程

Encrypt-JDBC将用户发起的SQL进行拦截，并通过SQL语法解析器进行解析、理解SQL行为，再依据用 户传入的脱敏规则，找出需要脱敏的字段和所使用的加解密器对目标字段进行加解密处理后，再与底层 数据库进行交互。

脱敏规则

脱敏配置主要分为四部分：数据源配置，加密器配置，脱敏表配置以及查询属性配置，其详情如下图所 示：

• 数据源配置：指DataSource的配置信息
• 加密器配置：指使用什么加密策略进行加解密。目前ShardingSphere内置了两种加解密策略： AES/MD5
• 脱敏表配置：指定哪个列用于存储密文数据（cipherColumn）、哪个列用于存储明文数据 （plainColumn）以及用户想使用哪个列进行SQL编写（logicColumn）
• 查询属性的配置（query.with.cipher.column）：当底层数据库表里同时存储了明文数据、密文数据后，该属性开关用于决定是直 接查询数据库表里的明文数据进行返回，还是查询密文数据通过Encrypt-JDBC解密后返回。

脱敏处理流程

下方图片展示了使用Encrypt-JDBC进行增删改查时，其中的处理流程和转换逻辑

加密解密解析

ShardingSphere提供了两种加密策略用于数据脱敏，该两种策略分别对应ShardingSphere的两种加解密的接口，即Encryptor和QueryAssistedEncryptor。

• Encryptor
  该解决方案通过提供encrypt(), decrypt()两种方法对需要脱敏的数据进行加解密。在用户进行 INSERT, DELETE, UPDATE时，ShardingSphere会按照用户配置，对SQL进行解析、改写、路由， 并会调用encrypt()将数据加密后存储到数据库, 而在SELECT时，则调用decrypt()方法将从数据库中取出的脱敏数据进行逆向解密，最终将原始数据返回给用户。 ShardingSphere针对这种类型的脱敏解决方案提供了两种具体实现类，分别是MD5(不可 逆)，AES(可逆)，用户只需配置即可使用这两种内置的方案。

• QueryAssistedEncryptor
  相比较于第一种脱敏方案，该方案更为安全和复杂。它的理念是：即使是相同的数据，如两个用户 的密码相同，它们在数据库里存储的脱敏数据也应当是不一样的。这种理念更有利于保护用户信 息，防止撞库成功。
  它提供三种函数进行实现，分别是encrypt(), decrypt(), queryAssistedEncrypt()。在encrypt()阶 段，用户通过设置某个变动种子，例如时间戳。针对原始数据+变动种子组合的内容进行加密，就能保证即使原始数据相同，也因为有变动种子的存在，致使加密后的脱敏数据是不一样的。在 decrypt()可依据之前规定的加密算法，利用种子数据进行解密。queryAssistedEncrypt()用于生成 辅助查询列，用于原始数据的查询过程。
  但是，ShardingSphere针对这种类型的脱敏解决方案并没有提供具体实现类，却将该理念抽象成接口，提供给用户自行实现。ShardingSphere将调用用户提供的该方案的具体实现类进行数据脱敏。

使用

配置文件

application-encryptor.properties

#打印sql
spring.shardingsphere.props.sql.show=true
#datasource
spring.shardingsphere.datasource.names=ds0
#数据库连接池类型
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
#连接信息
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://localhost:3306/order0?serverTimezone=GMT%2B8
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root
#指定表id生成策略
spring.shardingsphere.sharding.tables.c_user.key-generator.column=id
spring.shardingsphere.sharding.tables.c_user.key-generator.type=SNOWFLAKE
#算法属性 可以看没课策略里面可以配置的属性
spring.shardingsphere.sharding.tables.c_user.key-generator.props.worker.id=2
spring.shardingsphere.sharding.tables.c_user.key-generator.props.max.vibration.offset=3
#encryptor配置
#加密策略類型配置
spring.shardingsphere.encrypt.encryptors.c_user_pwd_encryptor.type=AES
#可以在AESEncryptor这个类里面看所需属性 aes加密解密key
spring.shardingsphere.encrypt.encryptors.c_user_pwd_encryptor.props.aes.key.value=123456
#指定加密策略
spring.shardingsphere.encrypt.tables.c_user.columns.pwd.encryptor=c_user_pwd_encryptor
#可以看 YamlEncryptColumnRuleConfiguration配置类里面的属性
#明文 pwd为逻辑列明  pwd_plain物理存在的明文列 可以不指定物理列，那么物理列就不会存入数据
#spring.shardingsphere.encrypt.tables.c_user.columns.pwd.plain-column=pwd_plain
#密文 物理存在的pwd_cipher密文列
spring.shardingsphere.encrypt.tables.c_user.columns.pwd.cipher-column=pwd_cipher
#默认为true 是否使用加密数据进行查询
spring.shardingsphere.query.with.cipher.column=true

测试类

@RunWith(SpringRunner.class)
@SpringBootTest(classes = ShardingJdbcApp.class)
public class EncryptorTest {
    @Autowired
    private CUserRepository cUserRepository;
    @Test
    public void addCUser(){
        CUser cUser = new CUser();
        cUser.setName("王哈哈");
        cUser.setPwd("root");
        cUserRepository.save(cUser);
    }
    @Test
    public void findByPwd(){
        //spring.shardingsphere.query.with.cipher.column=true 用密文进行查询
        CUser root = cUserRepository.findByPwd("root");
        System.out.println(root);
    }
}

实体

@Entity(name = "c_user")
public class CUser {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String pwd;
}

6 分布式理论回顾一下

6.1 CAP和BASE理论

CAP理论：CAP 定理，又被叫作布鲁尔定理。对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两 个都有其适应的场景。

BASE理论：BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。它的核心思想是即使无法做到强一致性（CAP 就是强一致性），但应用可以采用 适合的方式达到最终一致性。

BA指的是基本业务可用性，支持分区失败；
S表示柔性状态，也就是允许短时间内不同步；
E表示最终一致性，数据最终是一致的，但是实时是不一致的。

原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的需要，只有降低一致性和隔离性的要求。BASE 解决了 CAP 理论中没有考虑到的网络延迟问题，在BASE中用软状态和最终一 致，保证了延迟后的一致性。

6.2 2PC （强一致性）

2PC是Two-Phase Commit缩写，即两阶段提交，就是将事务的提交过程分为两个阶段来进行处 理。事务的发起者称协调者，事务的执行者称参与者。协调者统一协调参与者执行。

• 阶段一 准备阶段
  协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。 各参与者执行事务操作，但不提交事务，将 undo 和 redo 信息记入事务日志中。 如参与者执行成功，给协调者反馈 yes；如执行失败，给协调者反馈 no。

• 阶段二 提交阶段
  如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息； 否则，发送提交(commit)消息。

2PC 方案实现起来简单，实际项目中使用比较少，主要因为以下问题：

• 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶 颈。
• 可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
• 数据一致性问题：在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消 息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

6.3 3PC （强一致性）

3PC 三阶段提交，是两阶段提交的改进版本，与两阶段提交不同的是，同时在协调者和参与者中都引入超时机制。三阶段提交将两阶段的准备阶段拆分为 2 个阶段，插入了一个 preCommit 阶段，解决了原先在两阶段提交中，参与者在准备之后，由于协调者或参与者发生崩 溃或错误，而导致参与者无法知晓处于长时间等待的问题。

如果在指定的时间内协调者没有收到参与者的消息则默认失败。

• 阶段一 canCommit
  协调者向参与者发送 canCommit 请求，参与者如果可以提交就返回 yes 响应，否则返回 no 响应。

• 阶段二 preCommit
  协调者根据阶段一 canCommit 参与者的反应情况执行预提交事务或中断事务操作。

  • 参与者均反馈 yes：协调者向所有参与者发出 preCommit 请求，参与者收到 preCommit 请求后，执行事务操作，但不提交；将 undo 和 redo 信息记入事务日志 中；各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。
  • 任何一个参与者反馈 no或等待超时：协调者向所有参与者发出 abort 请求，无论收到 协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断本次事务。
• 阶段三 commint
  该阶段进行真正的事务提交，根据阶段二 preCommit反馈的结果完成事务提交或中断操作。

相比2PC模式，3PC模式降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段三中协调者出现问题时（比如网络中断等），参与者会继续提交事务。

如此，如果在第三阶段协调者如果发送abort请求，但是有的参与者没有收到abort请求出现超时时自动提交事务也会导致数据不一致性的问题。

7 分布式事务整合原理

7.1 XA（强一致性）

两阶段事务提交采用的是X/OPEN组织所定义的DTP模型，通过抽象出来的AP, TM, RM的概念可以保证事务的强一致性。 其中TM和RM间采用XA的协议进行双向通信。 与传统的本地事务相比，XA事务增加了prepare阶段，数据库除了被动接受提交指令外，还可以反向通知调用方事务是否可以被提交。 因此TM可以收集所有分支事务的prepare结果，最后进行原子的提交，保证事务的强一致性。基于数据库的XA协议来实现2PC又称为XA方案。

XA之所以需要引入事务管理器，是因为在分布式系统中，从理论上讲两台机器理论上无法达到一 致的状态，需要引入一个单点进行协调。由全局事务管理器管理和协调的事务，可以跨越多个资源 （数据库）和进程。

事务管理器用来保证所有的事务参与者都完成了准备工作(第一阶段)。如果事务管理器收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL 在这个XA事务中扮演的是RM的角色，而不是事务管理器。

7.2 TCC（最终一致性）

TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。TCC 是服务化的两阶段 编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现：

• Try 操作作为一阶段，负责资源的检查和预留；
• Confirm 操作作为二阶段提交操作，执行真正的业务；
• Cancel 是预留资源的取消；

TCC事务模式相对于 XA 等传统模型对比：

相比于XA，解决了：

• 解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器可以变成多点， 引入集群。
• 同步阻塞：引入超时机制，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
• 数据一致性，有了补偿机制之后，由业务活动管理器控制一致性。

消息队列模式（最终一致性）：

消息队列的方案最初是由 eBay 提出，基于TCC模式，消息中间件可以基于 Kafka、RocketMQ 等 消息队列。此方案的核心是将分布式事务拆分成本地事务进行处理，将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或MQ中间件，再通过业务规则人工发起重试。

处理流程：

• 步骤1：事务主动方处理本地事务。 事务主动方在本地事务中处理业务更新操作和MQ写消息操作。
• 步骤 2：事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息。 事务主动方主动写消息到MQ，事务消费方接收并处理MQ中的消息。
• 步骤 3：事务被动方通过MQ中间件，通知事务主动方事务已处理的消息，事务主动方根据反馈结果提交或回滚事务。

为了数据的一致性，当流程中遇到错误需要重试，容错处理规则如下：

• 当步骤 1 处理出错，事务回滚，相当于什么都没发生。
• 当步骤 2 处理出错，由于未处理的事务消息还是保存在事务发送方，可以重试或撤销本地业务操作。
• 如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等。
• 如果是事务被动方业务上的处理失败，可以通过MQ通知事务主动方进行补偿或者事务回滚。
• 如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。

7.3 Saga模式（最终一致性）

Saga这个概念源于 1987 年普林斯顿大学的 Hecto 和 Kenneth 发表的一篇数据库论文Sagas ，一 个Saga事务是一个有多个短时事务组成的长时的事务。 在分布式事务场景下，我们把一个Saga分 布式事务看做是一个由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务。在 Saga事务的执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复 成为事务执行之前的状态。（自动反向补偿机制）。

Saga 事务基本协议如下：

• 每个 Saga 事务由一系列幂等的有序子事务(sub-transaction) Ti 组成。
• 每个 Ti 都有对应的幂等补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果。

Saga是一种补偿模式，它定义了两种补偿策略：

• 向前恢复（forward recovery）：对应于上面第一种执行顺序，发生失败进行重试，适用于必须要成功的场景。
• 向后恢复（backward recovery）：对应于上面提到的第二种执行顺序，发生错误后撤销掉之前所有成功的子事务，使得整个 Saga 的执行结果撤销。

事务正常执行完成：T1, T2, T3, …, Tn，例如：减库存(T1)，创建订单(T2)，支付(T3)，依次有序完 成整个事务。

事务回滚：T1, T2, …, Tj, Cj,…, C2, C1，其中 0 < j < n，例如：减库存(T1)，创建订单(T2)，支付 (T3)，支付失败，支付回滚(C3)，订单回滚(C2)，恢复库存(C1)。

7.4 Seta框架

Fescar开源项目，最初愿景是能像本地事务一样控制分布式事务，解决分布式环境下的难题。

Seata（Simple Extensible Autonomous Transaction Architecture）是一套一站式分布式事务解决方案，是阿里集团和蚂蚁金服联合打造的分布式事务框架。Seata目前的事务模式有AT、TCC、 Saga和XA，默认是AT模式，AT本质上是2PC协议的一种实现。

Seata AT事务模型包含TM(事务管理器)，RM(资源管理器)，TC(事务协调器)。其中TC是一个独立 的服务需要单独部署，TM和RM以jar包的方式同业务应用部署在一起，它们同TC建立长连接，在 整个事务生命周期内，保持RPC通信。

• 全局事务的发起方作为TM，全局事务的参与者作为RM
• TM负责全局事务的begin和commit/rollback
• RM负责分支事务的执行结果上报，并且通过TC的协调进行commit/rollback。

在 Seata 中，AT时分为两个阶段的，

• 第一阶段，就是各个阶段本地提交操作；
• 第二阶段会根据第 一阶段的情况决定是进行全局提交还是全局回滚操作。

具体的执行流程如下：

• TM 开启分布式事务，负责全局事务的begin和commit/rollback（TM 向 TC 注册全局事务记 录）； -
• RM 作为参与者，负责分支事务的执行结果上报，并且通过TC的协调进行 commit/rollback（RM 向 TC 汇报资源准备状态 ）；
• RM分支事务结束，事务一阶段结束;
• 根据TC 汇总事务信息，由TM发起事务提交或回滚操作；
• TC 通知所有 RM 提交/回滚资源，事务二阶段结束；

7.5 Sharding整合XA原理

Java通过定义JTA接口实现了XA的模型，JTA接口里的ResourceManager需要数据库厂商提供XA的驱动 实现，而TransactionManager则需要事务管理器的厂商实现，传统的事务管理器需要同应用服务器绑 定，因此使用的成本很高。 而嵌入式的事务管器可以以jar包的形式提供服务，同ShardingSphere集成 后，可保证分片后跨库事务强一致性。

ShardingSphere支持以下功能：

• 支持数据分片后的跨库XA事务
• 两阶段提交保证操作的原子性和数据的强一致性
• 服务宕机重启后，提交/回滚中的事务可自动恢复
• SPI机制整合主流的XA事务管理器，默认Atomikos
• 同时支持XA和非XA的连接池
• 提供spring-boot和namespace的接入端

ShardingSphere整合XA事务时，分离了XA事务管理和连接池管理，这样接入XA时，可以做到对业务的零侵入。

• Begin（开启XA全局事务）
  XAShardingTransactionManager会调用具体的XA事务管理器开启XA的全局事务。

• 执行物理SQL ShardingSphere进行解析/优化/路由后会生成SQL操作，执行引擎为每个物理SQL创建连接的同时，物理连接所对应的XAResource也会被注册到当前XA事务中。事务管理器会在此阶段发送 XAResource.start命令给数据库，数据库在收到XAResource.end命令之前的所有SQL操作，会被 标记为XA事务。

  XAResource1.start ## Enlist阶段执行
  statement.execute("sql1"); ## 模拟执行一个分片SQL1
  statement.execute("sql2"); ## 模拟执行一个分片SQL2
  XAResource1.end ## 提交阶段执行

执行这里sql1和sql2将会被标记为XA事务。

• Commit/rollback（提交XA事务）
  XAShardingTransactionManager收到接入端的提交命令后，会委托实际的XA事务管理进行提交动作，这时事务管理器会收集当前线程里所有注册的XAResource，首先发送XAResource.end指令，用以标记此XA事务的边界。 接着会依次发送prepare指令，收集所有参与XAResource投票， 如果所有XAResource的反馈结果都是OK，则会再次调用commit指令进行最终提交，如果有一个 XAResource的反馈结果为No，则会调用rollback指令进行回滚。 在事务管理器发出提交指令后， 任何XAResource产生的异常都会通过recovery日志进行重试，来保证提交阶段的操作原子性，和数据强一致性。

  XAResource1.prepare ## ack: yes
  XAResource2.prepare ## ack: yes
  XAResource1.commit
  XAResource2.commit
  XAResource1.prepare ## ack: yes
  XAResource2.prepare ## ack: no
  XAResource1.rollback
  XAResource2.rollback

7.6 Sharding-JDBC整合Saga原理

ShardingSphere的柔性事务已通过第三方servicecomb-saga组件实现的，通过SPI机制注入使用。 ShardingSphere是基于反向SQL技术实现的反向补偿操作，它将对数据库进行更新操作的SQL自动生成 反向SQL，并交由Saga-actuator引擎执行。使用方则无需再关注如何实现补偿方法，将柔性事务管理器 的应用范畴成功的定位回了事务的本源——数据库层面。ShardingSphere支持以下功能：

完全支持跨库事务支持失败SQL重试及最大努力送达支持反向SQL、自动生成更新快照以及自动补偿 默认使用关系型数据库进行快照及事务日志的持久化，支持使用SPI的方式加载其他类型的持久化。

Saga柔性事务的实现类为SagaShardingTransactionMananger, ShardingSphere通过Hook的方式拦截逻辑SQL的解析和路由结果，这样，在分片物理SQL执行前，可以生成逆向SQL，在事务提交阶段再把SQL调用链交给Saga引擎处理。

执行流程：

• Init（Saga引擎初始化） 包含Saga柔性事务的应用启动时，saga-actuator引擎会根据saga.properties的配置进行初始化的 流程。
• Begin（开启Saga全局事务） 每次开启Saga全局事务时，将会生成本次全局事务的上下文（SagaTransactionContext），事务上下文记录了所有子事务的正向SQL和逆向SQL，作为生成事务调用链的元数据使用。
• 执行物理SQL 在物理SQL执行前，ShardingSphere根据SQL的类型生成逆向SQL，这里是通过Hook的方式拦截 Parser的解析结果进行实现。
• Commit/rollback（提交Saga事务） 提交阶段会生成Saga执行引擎所需的调用链路图，commit操作产生ForwardRecovery（正向SQL 补偿）任务，rollback操作产生BackwardRecovery任务（逆向SQL补偿）。

7.7 Sharding-JDBC整合Seata原理

Seata AT事务作为BASE柔性事务的一种实现，可以无缝接入到ShardingSphere生态中。在整合Seata AT事务时，需要把TM，RM，TC的模型融入到ShardingSphere 分布式事务的SPI的生态中。在数据库资源上，Seata通过对接DataSource接口，让JDBC操作可以同TC进行RPC通信。同样， ShardingSphere也是面向DataSource接口对用户配置的物理DataSource进行了聚合，因此把物理 DataSource二次包装为Seata 的DataSource后，就可以把Seata AT事务融入到ShardingSphere的分片 中。

• Init（Seata引擎初始化）
  包含Seata柔性事务的应用启动时，用户配置的数据源会按seata.conf的配置，适配成Seata事务所 需的DataSourceProxy，并且注册到RM中。

• Begin（开启Seata全局事务）
  TM控制全局事务的边界，TM通过向TC发送Begin指令，获取全局事务ID，所有分支事务通过此全 局事务ID，参与到全局事务中；全局事务ID的上下文存放在当前线程变量中。

• 执行分片物理SQL
  处于Seata全局事务中的分片SQL通过RM生成undo快照，并且发送participate指令到TC，加入到全局事务中。ShardingSphere的分片物理SQL是按多线程方式执行，因此整合Seata AT事务时， 需要在主线程和子线程间进行全局事务ID的上下文传递，这同服务间的上下文传递思路完全相同。

• Commit/rollback（提交Seata事务）
  提交Seata事务时，TM会向TC发送全局事务的commit和rollback指令，TC根据全局事务ID协调所有分支事务进行commit和rollback。

8 分布式事务整合

sharding-jdbc和xa,saga,seata整合起来很方便，底层把细节都封装好了。面试的时候主要就是问一下前面的理论以及底层实现的原理。

依赖，用什么引入什么就可以

//XA模式
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-transaction-xa-core</artifactId>
<version>${shardingsphere.version}</version>
</dependency>
//Saga模式
<dependency>
<groupId>io.shardingsphere</groupId>
<artifactId>sharding-transaction-base-saga</artifactId>
<version>${shardingsphere-spi-impl.version}</version>
</dependency>
//Seata模式
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-transaction-base-seata-at</artifactId>
<version>${sharding-sphere.version}</version>
</dependency>

在需要标注事务的方法加@Transactional注解和@ShardingTransactionType然后指定TransactionType

参数配置：

ShardingSphere默认的XA事务管理器为Atomikos，通过在项目的classpath中添加jta.properties 来定制化Atomikos配置项。

#指定是否启动磁盘日志，默认为true。在生产环境下一定要保证为true，否则数据的完整性无法保证
com.atomikos.icatch.enable_logging=true
#JTA/XA资源是否应该自动注册
com.atomikos.icatch.automatic_resource_registration=true
#JTA事务的默认超时时间，默认为10000ms
com.atomikos.icatch.default_jta_timeout=10000
#事务的最大超时时间，默认为300000ms。这表示事务超时时间由 UserTransaction.setTransactionTimeout()较大者决定。4.x版本之后，指定为0的话则表示不设置超时时间
com.atomikos.icatch.max_timeout=300000
#指定在两阶段提交时，是否使用不同的线程(意味着并行)。3.7版本之后默认为false，更早的版本默认为true。如果为false，则提交将按照事务中访问资源的顺序进行。
com.atomikos.icatch.threaded_2pc=false
#指定最多可以同时运行的事务数量，默认值为50，负数表示没有数量限制。在调用 UserTransaction.begin()方法时，可能会抛出一个”Max number of active transactions reached”异常信息，表示超出最大事务数限制
com.atomikos.icatch.max_actives=50
#是否支持subtransaction，默认为true
com.atomikos.icatch.allow_subtransactions=true
#指定在可能的情况下，否应该join 子事务(subtransactions)，默认值为true。如果设置为false，对于有关联的不同subtransactions，不会调用XAResource.start(TM_JOIN)
com.atomikos.icatch.serial_jta_transactions=true
#指定JVM关闭时是否强制(force)关闭事务管理器，默认为false
com.atomikos.icatch.force_shutdown_on_vm_exit=false
#在正常关闭(no-force)的情况下，应该等待事务执行完成的时间，默认为Long.MAX_VALUE
com.atomikos.icatch.default_max_wait_time_on_shutdown=9223372036854775807
===============================================================
=========        事务日志(Transaction logs)记录配置       =======
===============================================================
#事务日志目录，默认为./。
com.atomikos.icatch.log_base_dir=./
#事务日志文件前缀，默认为tmlog。事务日志存储在文件中，文件名包含一个数字后缀，日志文件以.log为扩展名，如tmlog1.log。遇到checkpoint时，新的事务日志文件会被创建，数字增加。
com.atomikos.icatch.log_base_name=tmlog
#指定两次checkpoint的时间间隔，默认为500
com.atomikos.icatch.checkpoint_interval=500
===============================================================
=========          事务日志恢复(Recovery)配置       =============
===============================================================
#指定在多长时间后可以清空无法恢复的事务日志(orphaned)，默认86400000ms
com.atomikos.icatch.forget_orphaned_log_entries_delay=86400000
#指定两次恢复扫描之间的延迟时间。默认值为与com.atomikos.icatch.default_jta_timeout相同
com.atomikos.icatch.recovery_delay=${com.atomikos.icatch.default_jta_timeout}
#提交失败时，再抛出一个异常之前，最多可以重试几次，默认值为5
com.atomikos.icatch.oltp_max_retries=5
#提交失败时，每次重试的时间间隔，默认10000ms
com.atomikos.icatch.oltp_retry_interval=10000
===============================================================
=========          其他       =============================== ==
===============================================================
java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
com.atomikos.icatch.client_demarcation=false
java.naming.provider.url=rmi://localhost:1099
com.atomikos.icatch.rmi_export_class=none
com.atomikos.icatch.trust_client_tm=false