程序员内点事个人页面-阿里云开发者社区

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

好长时间没发文了，最近着实是有点忙，当爹的第 43 天，身心疲惫。这又赶上年底，公司冲 KPI 强制技术部加班到十点，晚上孩子隔两三个小时一醒，基本没睡囫囵觉的机会，天天处于迷糊的状态，孩子还时不时起一些奇奇怪怪的疹子，总让人担惊受怕的。本就不多的写文章时间又被无限分割，哎~ 打工人真是太难了。本来不知道写点啥，正好手头有个新项目试着用阿里的 Seata 中间件做分布式事务，那就做一个实践分享吧！介绍 Seata 之前在简单回顾一下分布式事务的基本概念。分布式事务的产生我们先看看百度上对于分布式事务的定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。额~ 有点抽象，简单的画个图好理解一下，拿下单减库存、扣余额来说举例：当系统的体量很小时，单体架构完全可以满足现有业务需求，所有的业务共用一个数据库，整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。此时做到所有操作要么全部提交或要么全部回滚很容易。分库分表、SOA 可随着业务量的不断增长，单体架构渐渐扛不住巨大的流量，此时就需要对数据库、表做分库分表处理，将应用 SOA 服务化拆分。也就产生了订单中心、用户中心、库存中心等，由此带来的问题就是业务间相互隔离，每个业务都维护着自己的数据库，数据的交换只能进行 RPC 调用。当用户再次下单时，需同时对订单库 order、库存库 storage、用户库 account 进行操作，可此时我们只能保证自己本地的数据一致性，无法保证调用其他服务的操作是否成功，所以为了保证整个下单流程的数据一致性，就需要分布式事务介入。 Seata 优势实现分布式事务的方案比较多，常见的比如基于 XA 协议的 2PC、3PC，基于业务层的 TCC，还有应用消息队列 + 消息表实现的最终一致性方案，还有今天要说的 Seata 中间件，下边看看各个方案的优缺点。 2PC 基于 XA 协议实现的分布式事务，XA 协议中分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如 Oracle、MYSQL 这些数据库都实现了 XA 接口，而事务管理器则作为一个全局的调度者。两阶段提交（2PC），对业务侵⼊很小，它最⼤的优势就是对使⽤⽅透明，用户可以像使⽤本地事务⼀样使⽤基于 XA 协议的分布式事务，能够严格保障事务 ACID 特性。可 2PC的缺点也是显而易见，它是一个强一致性的同步阻塞协议，事务执⾏过程中需要将所需资源全部锁定，也就是俗称的刚性事务。所以它比较适⽤于执⾏时间确定的短事务，整体性能比较差。一旦事务协调者宕机或者发生网络抖动，会让参与者一直处于锁定资源的状态或者只有一部分参与者提交成功，导致数据的不一致。因此，在⾼并发性能⾄上的场景中，基于 XA 协议的分布式事务并不是最佳选择。 3PC 三段提交（3PC）是二阶段提交（2PC）的一种改进版本，为解决两阶段提交协议的阻塞问题，上边提到两段提交，当协调者崩溃时，参与者不能做出最后的选择，就会一直保持阻塞锁定资源。 2PC 中只有协调者有超时机制，3PC 在协调者和参与者中都引入了超时机制，协调者出现故障后，参与者就不会一直阻塞。而且在第一阶段和第二阶段中又插入了一个准备阶段（如下图，看着有点啰嗦），保证了在最后提交阶段之前各参与节点的状态是一致的。虽然 3PC 用超时机制，解决了协调者故障后参与者的阻塞问题，但与此同时却多了一次网络通信，性能上反而变得更差，也不太推荐。 TCC 所谓的 TCC 编程模式，也是两阶段提交的一个变种，不同的是 TCC 为在业务层编写代码实现的两阶段提交。TCC 分别指 Try、Confirm、Cancel ，一个业务操作要对应的写这三个方法。以下单扣库存为例，Try 阶段去占库存，Confirm 阶段则实际扣库存，如果库存扣减失败 Cancel 阶段进行回滚，释放库存。 TCC 不存在资源阻塞的问题，因为每个方法都直接进行事务的提交，一旦出现异常通过则 Cancel 来进行回滚补偿，这也就是常说的补偿性事务。原本一个方法，现在却需要三个方法来支持，可以看到 TCC 对业务的侵入性很强，而且这种模式并不能很好地被复用，会导致开发量激增。还要考虑到网络波动等原因，为保证请求一定送达都会有重试机制，所以考虑到接口的幂等性。消息事务（最终一致性）消息事务其实就是基于消息中间件的两阶段提交，将本地事务和发消息放在同一个事务里，保证本地操作和发送消息同时成功。下单扣库存原理图：订单系统向 MQ 发送一条预备扣减库存消息，MQ 保存预备消息并返回成功 ACK 接收到预备消息执行成功 ACK，订单系统执行本地下单操作，为防止消息发送成功而本地事务失败，订单系统会实现 MQ 的回调接口，其内不断的检查本地事务是否执行成功，如果失败则 rollback 回滚预备消息；成功则对消息进行最终 commit 提交。库存系统消费扣减库存消息，执行本地事务，如果扣减失败，消息会重新投，一旦超出重试次数，则本地表持久化失败消息，并启动定时任务做补偿。基于消息中间件的两阶段提交方案，通常用在高并发场景下使用，牺牲数据的强一致性换取性能的大幅提升，不过实现这种方式的成本和复杂度是比较高的，还要看实际业务情况。 Seata Seata 也是从两段提交演变而来的一种分布式事务解决方案，提供了 AT、TCC、SAGA 和 XA 等事务模式，这里重点介绍 AT模式。既然 Seata 是两段提交，那我们看看它在每个阶段都做了点啥？下边我们还以下单扣库存、扣余额举例。先介绍 Seata 分布式事务的几种角色： Transaction Coordinator(TC): 全局事务协调者，用来协调全局事务和各个分支事务（不同服务）的状态，驱动全局事务和各个分支事务的回滚或提交。 Transaction Manager™ : 事务管理者，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）。 Resource Manager(RM): 资源管理者，一般指业务数据库代表了一个分支事务（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚。 Seata 实现分布式事务，设计了一个关键角色 UNDO_LOG （回滚日志记录表），我们在每个应用分布式事务的业务库中创建这张表，这个表的核心作用就是，将业务数据在更新前后的数据镜像组织成回滚日志，备份在 UNDO_LOG 表中，以便业务异常能随时回滚。第一个阶段比如：下边我们更新 user 表的 name 字段。 update user set name = '小富最帅' where name = '程序员内点事' 首先 Seata 的 JDBC 数据源代理通过对业务 SQL 解析，提取 SQL 的元数据，也就是得到 SQL 的类型（UPDATE），表（user），条件（where name = '程序员内点事'）等相关的信息。先查询数据前镜像，根据解析得到的条件信息，生成查询语句，定位一条数据。 select name from user where name = '程序员内点事' 紧接着执行业务 SQL，根据前镜像数据主键查询出后镜像数据 select name from user where id = 1 把业务数据在更新前后的数据镜像组织成回滚日志，将业务数据的更新和回滚日志在同一个本地事务中提交，分别插入到业务表和 UNDO_LOG 表中。回滚记录数据格式如下：包括 afterImage 前镜像、beforeImage 后镜像、 branchId 分支事务ID、xid 全局事务ID { "branchId":641789253, "xid":"xid:xxx", "undoItems":[ { "afterImage":{ "rows":[ { "fields":[ { "name":"id", "type":4, "value":1 } ] } ], "tableName":"product" }, "beforeImage":{ "rows":[ { "fields":[ { "name":"id", "type":4, "value":1 } ] } ], "tableName":"product" }, "sqlType":"UPDATE" } ] } 这样就可以保证，任何提交的业务数据的更新一定有相应的回滚日志。在本地事务提交前，各分支事务需向全局事务协调者 TC 注册分支 ( Branch Id) ，为要修改的记录申请全局锁，要为这条数据加锁，利用 SELECT FOR UPDATE 语句。而如果一直拿不到锁那就需要回滚本地事务。TM 开启事务后会生成全局唯一的 XID，会在各个调用的服务间进行传递。有了这样的机制，本地事务分支（Branch Transaction）便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源。相比于传统的 XA 事务在第二阶段释放资源，Seata 降低了锁范围提高效率，即使第二阶段发生异常需要回滚，也可以快速从UNDO_LOG 表中找到对应回滚数据并反解析成 SQL 来达到回滚补偿。最后本地事务提交，业务数据的更新和前面生成的 UNDO LOG 数据一并提交，并将本地事务提交的结果上报给全局事务协调者 TC。第二个阶段第二阶段是根据各分支的决议做提交或回滚：如果决议是全局提交，此时各分支事务已提交并成功，这时全局事务协调者（TC）会向分支发送第二阶段的请求。收到 TC 的分支提交请求，该请求会被放入一个异步任务队列中，并马上返回提交成功结果给 TC。异步队列中会异步和批量地根据 Branch ID 查找并删除相应 UNDO LOG 回滚记录。如果决议是全局回滚，过程比全局提交麻烦一点，RM 服务方收到 TC 全局协调者发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。注意：这里删除回滚日志记录操作，一定是在本地业务事务执行之后上边说了几种分布式事务各自的优缺点，下边实践一下分布式事务中间 Seata 感受一下。 Seata 实践 Seata 是一个需独立部署的中间件，所以先搭 Seata Server，这里以最新的 seata-server-1.4.0 版本为例，下载地址：https://seata.io/en-us/blog/download.html 解压后的文件我们只需要关心 \seata\conf 目录下的 file.conf 和 registry.conf 文件。 Seata Server file.conf file.conf 文件用于配置持久化事务日志的模式，目前提供 file、db、redis 三种方式。注意：在选择 db 方式后，需要在对应数据库创建 globalTable（持久化全局事务）、branchTable（持久化各提交分支的事务）、 lockTable（持久化各分支锁定资源事务）三张表。 -- the table to store GlobalSession data -- 持久化全局事务 CREATE TABLE IF NOT EXISTS `global_table` ( `xid` VARCHAR(128) NOT NULL, `transaction_id` BIGINT, `status` TINYINT NOT NULL, `application_id` VARCHAR(32), `transaction_service_group` VARCHAR(32), `transaction_name` VARCHAR(128), `timeout` INT, `begin_time` BIGINT, `application_data` VARCHAR(2000), `gmt_create` DATETIME, `gmt_modified` DATETIME, PRIMARY KEY (`xid`), KEY `idx_gmt_modified_status` (`gmt_modified`, `status`), KEY `idx_transaction_id` (`transaction_id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8; -- the table to store BranchSession data -- 持久化各提交分支的事务 CREATE TABLE IF NOT EXISTS `branch_table` ( `branch_id` BIGINT NOT NULL, `xid` VARCHAR(128) NOT NULL, `transaction_id` BIGINT, `resource_group_id` VARCHAR(32), `resource_id` VARCHAR(256), `branch_type` VARCHAR(8), `status` TINYINT, `client_id` VARCHAR(64), `application_data` VARCHAR(2000), `gmt_create` DATETIME(6), `gmt_modified` DATETIME(6), PRIMARY KEY (`branch_id`), KEY `idx_xid` (`xid`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8; -- the table to store lock data -- 持久化每个分支锁表事务 CREATE TABLE IF NOT EXISTS `lock_table` ( `row_key` VARCHAR(128) NOT NULL, `xid` VARCHAR(96), `transaction_id` BIGINT, `branch_id` BIGINT NOT NULL, `resource_id` VARCHAR(256), `table_name` VARCHAR(32), `pk` VARCHAR(36), `gmt_create` DATETIME, `gmt_modified` DATETIME, PRIMARY KEY (`row_key`), KEY `idx_branch_id` (`branch_id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8; registry.conf registry.conf 文件设置注册中心和配置中心：目前注册中心支持 nacos 、eureka、redis、zk、consul、etcd3、sofa 七种，这里我使用的 eureka作为注册中心；配置中心支持 nacos 、apollo、zk、consul、etcd3 五种方式。配置完以后在 \seata\bin 目录下启动 seata-server 即可，到这 Seata 的服务端就搭建好了。 Seata Client Seata Server 环境搭建完，接下来我们新建三个服务 order-server（下单服务）、storage-server（扣减库存服务）、account-server（账户金额服务），分别服务注册到 eureka。每个服务的大体核心配置如下： spring: application: name: storage-server cloud: alibaba: seata: tx-service-group: my_test_tx_group datasource: driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://47.93.6.1:3306/seat-storage username: root password: root # eureka 注册中心 eureka: client: serviceUrl: defaultZone: http://${eureka.instance.hostname}:8761/eureka/ instance: hostname: 47.93.6.5 prefer-ip-address: true 业务大致流程：用户发起下单请求，本地 order 订单服务创建订单记录，并通过 RPC 远程调用 storage 扣减库存服务和 account 扣账户余额服务，只有三个服务同时执行成功，才是一个完整的下单流程。如果某个服执行失败，则其他服务全部回滚。 Seata 对业务代码的侵入性非常小，代码中使用只需用 @GlobalTransactional 注解开启一个全局事务即可。 @Override @GlobalTransactional(name = "create-order", rollbackFor = Exception.class) public void create(Order order) { String xid = RootContext.getXID(); LOGGER.info("------->交易开始"); //本地方法 orderDao.create(order); //远程方法扣减库存 storageApi.decrease(order.getProductId(), order.getCount()); //远程方法扣减账户余额 LOGGER.info("------->扣减账户开始order中"); accountApi.decrease(order.getUserId(), order.getMoney()); LOGGER.info("------->扣减账户结束order中"); LOGGER.info("------->交易结束"); LOGGER.info("全局事务 xid： {}", xid); } 前边说过 Seata AT 模式实现分布式事务，必须在相关的业务库中创建 undo_log 表来存数据回滚日志，表结构如下： -- for AT mode you must to init this sql for you business database. the seata server not need it. CREATE TABLE IF NOT EXISTS `undo_log` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 'increment id', `branch_id` BIGINT(20) NOT NULL COMMENT 'branch transaction id', `xid` VARCHAR(100) NOT NULL COMMENT 'global transaction id', `context` VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization', `rollback_info` LONGBLOB NOT NULL COMMENT 'rollback info', `log_status` INT(11) NOT NULL COMMENT '0:normal status,1:defense status', `log_created` DATETIME NOT NULL COMMENT 'create datetime', `log_modified` DATETIME NOT NULL COMMENT 'modify datetime', PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`) ) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT ='AT transaction mode undo table'; 到这环境搭建的工作就完事了，完整案例会在后边贴出 GitHub 地址，就不在这占用篇幅了。测试 Seata 项目中的服务调用过程如下图：启动各个服务后，我们直接请求下单接口看看效果，只要 order 订单表创建记录成功，storage 库存表 used 字段数量递增、account 余额表 used 字段数量递增则表示下单流程成功。请求后正向流程是没问题的，数据和预想的一样而且发现 TM 事务管理者 order-server 服务的控制台也打印出了两阶段提交的日志那么再看看如果其中一个服务异常，会不会正常回滚呢？在 account-server 服务中模拟超时异常，看能否实现全局事务回滚。发现数据全没执行成功，说明全局事务回滚也成功了那看一下 undo_log 回滚记录表的变化情况，由于 Seata 删除回滚日志的速度很快，所以要想在表中看见回滚日志，必须要在某一个服务上打断点才看的更明显。总结上边简单介绍了 2PC、3PC、TCC、MQ、Seata 这五种分布式事务解决方案，还详细的实践了 Seata 中间件。但不管我们选哪一种方案，在项目中应用都要谨慎再谨慎，除特定的数据强一致性场景外，能不用尽量就不要用，因为无论它们性能如何优越，一旦项目套上分布式事务，整体效率会几倍的下降，在高并发情况下弊端尤为明显。本案例 github 地址：https://github.com/chengxy-nds/Springboot-Notebook/tree/master/springboot-seata-transaction 如果有一丝收获，欢迎点赞、转发，您的认可是我最大的动力。整理了几百本各类技术电子书，有需要的同学可以，关注公号回复 [ 666 ] 自取。还有想要加技术群的可以加我好友，和大佬侃技术、不定期内推，一起学起来。

分库分表的 9种分布式主键ID 生成方案，挺全乎的

《sharding-jdbc 分库分表的 4种分片策略》中我们介绍了 sharding-jdbc 4种分片策略的使用场景，可以满足基础的分片功能开发，这篇我们来看看分库分表后，应该如何为分片表生成全局唯一的主键 ID。引入任何一种技术都是存在风险的，分库分表当然也不例外，除非库、表数据量持续增加，大到一定程度，以至于现有高可用架构已无法支撑，否则不建议大家做分库分表，因为做了数据分片后，你会发现自己踏上了一段踩坑之路，而分布式主键 ID 就是遇到的第一个坑。不同数据节点间生成全局唯一主键是个棘手的问题，一张逻辑表 t_order 拆分成多个真实表 t_order_n，然后被分散到不同分片库 db_0、db_1... ，各真实表的自增键由于无法互相感知从而会产生重复主键，此时数据库本身的自增主键，就无法满足分库分表对主键全局唯一的要求。 db_0-- |-- t_order_0 |-- t_order_1 |-- t_order_2 db_1-- |-- t_order_0 |-- t_order_1 |-- t_order_2 尽管我们可以通过严格约束，各个分片表自增主键的初始值和步长的方式来解决 ID 重复的问题，但这样会让运维成本陡增，而且可扩展性极差，一旦要扩容分片表数量，原表数据变动比较大，所以这种方式不太可取。步长 step = 分表张数 db_0-- |-- t_order_0 ID: 0、6、12、18... |-- t_order_1 ID: 1、7、13、19... |-- t_order_2 ID: 2、8、14、20... db_1-- |-- t_order_0 ID: 3、9、15、21... |-- t_order_1 ID: 4、10、16、22... |-- t_order_2 ID: 5、11、17、23... 目前已经有了许多第三放解决方案可以完美解决这个问题，比如基于 UUID、SNOWFLAKE算法、segment号段，使用特定算法生成不重复键，或者直接引用主键生成服务，像美团（Leaf）和滴滴（TinyId）等。而sharding-jdbc 内置了两种分布式主键生成方案，UUID、SNOWFLAKE，不仅如此它还抽离出分布式主键生成器的接口，以便于开发者实现自定义的主键生成器，后续我们会在自定义的生成器中接入滴滴（TinyId）的主键生成服务。前边介绍过在 sharding-jdbc 中要想为某个字段自动生成主键 ID，只需要在 application.properties 文件中做如下配置: # 主键字段 spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id # 主键ID 生成方案 spring.shardingsphere.sharding.tables.t_order.key-generator.type=UUID # 工作机器 id spring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123 key-generator.column 表示主键字段，key-generator.type 为主键 ID 生成方案（内置或自定义的），key-generator.props.worker.id 为机器ID，在主键生成方案设为 SNOWFLAKE 时机器ID 会参与位运算。在使用 sharding-jdbc 分布式主键时需要注意两点：一旦 insert 插入操作的实体对象中主键字段已经赋值，那么即使配置了主键生成方案也会失效，最后SQL 执行的数据会以赋的值为准。不要给主键字段设置自增属性，否则主键ID 会以默认的 SNOWFLAKE 方式生成。比如：用 mybatis plus 的 @TableId 注解给字段 order_id 设置了自增主键，那么此时配置哪种方案，总是按雪花算法生成。下面我们从源码上分析下 sharding-jdbc 内置主键生成方案 UUID、SNOWFLAKE 是怎么实现的。 UUID 打开 UUID 类型的主键生成实现类 UUIDShardingKeyGenerator 的源码发现，它的生成规则只有 UUID.randomUUID() 这么一行代码，额~ 心中默默来了一句卧槽。 UUID 虽然可以做到全局唯一性，但还是不推荐使用它作为主键，因为我们的实际业务中不管是 user_id 还是 order_id 主键多为整型，而 UUID 生成的是个 32 位的字符串。它的存储以及查询对 MySQL 的性能消耗较大，而且 MySQL 官方也明确建议，主键要尽量越短越好，作为数据库主键 UUID 的无序性还会导致数据位置频繁变动，严重影响性能。 public final class UUIDShardingKeyGenerator implements ShardingKeyGenerator { private Properties properties = new Properties(); public UUIDShardingKeyGenerator() { } public String getType() { return "UUID"; } public synchronized Comparable<?> generateKey() { return UUID.randomUUID().toString().replaceAll("-", ""); } public Properties getProperties() { return this.properties; } public void setProperties(Properties properties) { this.properties = properties; } } SNOWFLAKE SNOWFLAKE（雪花算法）是默认使用的主键生成方案，生成一个 64bit的长整型（Long）数据。 sharding-jdbc 中雪花算法生成的主键主要由 4部分组成，1bit符号位、41bit时间戳位、10bit工作进程位以及 12bit 序列号位。符号位（1bit位） Java 中 Long 型的最高位是符号位，正数是0，负数是1，一般生成ID都为正数，所以默认为0 时间戳位（41bit） 41位的时间戳可以容纳的毫秒数是 2 的 41次幂，而一年的总毫秒数为 1000L * 60 * 60 * 24 * 365，计算使用时间大概是69年，额~，我有生之间算是够用了。 Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L) = = 69年工作进程位（10bit）表示一个唯一的工作进程id，默认值为 0，可通过 key-generator.props.worker.id 属性设置。 spring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=0000 序列号位（12bit）同一毫秒内生成不同的ID。时钟回拨了解了雪花算法的主键 ID 组成后不难发现，这是一种严重依赖于服务器时间的算法，而依赖服务器时间的就会遇到一个棘手的问题：时钟回拨。为什么会出现时钟回拨呢？互联网中有一种网络时间协议 ntp 全称 (Network Time Protocol) ，专门用来同步、校准网络中各个计算机的时间。这就是为什么，我们的手机现在不用手动校对时间，可每个人的手机时间还都是一样的。我们的硬件时钟可能会因为各种原因变得不准（快了或慢了），此时就需要 ntp 服务来做时间校准，做校准的时候就会发生服务器时钟的跳跃或者回拨的问题。雪花算法如何解决时钟回拨服务器时钟回拨会导致产生重复的 ID，SNOWFLAKE 方案中对原有雪花算法做了改进，增加了一个最大容忍的时钟回拨毫秒数。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序直接报错；如果在可容忍的范围内，默认分布式主键生成器，会等待时钟同步到最后一次主键生成的时间后再继续工作。最大容忍的时钟回拨毫秒数，默认值为 0，可通过属性 max.tolerate.time.difference.milliseconds 设置。 # 最大容忍的时钟回拨毫秒数 spring.shardingsphere.sharding.tables.t_order.key-generator.max.tolerate.time.difference.milliseconds=5 下面是看下它的源码实现类 SnowflakeShardingKeyGenerator，核心流程大概如下：最后一次生成主键的时间 lastMilliseconds 与当前时间currentMilliseconds 做比较，如果 lastMilliseconds > currentMilliseconds则意味着时钟回调了。那么接着判断两个时间的差值（timeDifferenceMilliseconds）是否在设置的最大容忍时间阈值 max.tolerate.time.difference.milliseconds内，在阈值内则线程休眠差值时间 Thread.sleep(timeDifferenceMilliseconds)，否则大于差值直接报异常。 /** * @author xiaofu */ public final class SnowflakeShardingKeyGenerator implements ShardingKeyGenerator{ @Getter @Setter private Properties properties = new Properties(); public String getType() { return "SNOWFLAKE"; } public synchronized Comparable<?> generateKey() { /** * 当前系统时间毫秒数 */ long currentMilliseconds = timeService.getCurrentMillis(); /** * 判断是否需要等待容忍时间差，如果需要，则等待时间差过去，然后再获取当前系统时间 */ if (waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) { currentMilliseconds = timeService.getCurrentMillis(); } /** * 如果最后一次毫秒与当前系统时间毫秒相同，即还在同一毫秒内 */ if (lastMilliseconds == currentMilliseconds) { /** * &位与运算符：两个数都转为二进制，如果相对应位都是1，则结果为1，否则为0 * 当序列为4095时，4095+1后的新序列与掩码进行位与运算结果是0 * 当序列为其他值时，位与运算结果都不会是0 * 即本毫秒的序列已经用到最大值4096，此时要取下一个毫秒时间值 */ if (0L == (sequence = (sequence + 1) & SEQUENCE_MASK)) { currentMilliseconds = waitUntilNextTime(currentMilliseconds); } } else { /** * 上一毫秒已经过去，把序列值重置为1 */ vibrateSequenceOffset(); sequence = sequenceOffset; } lastMilliseconds = currentMilliseconds; /** * XX......XX XX000000 00000000 00000000 时间差 XX * XXXXXX XXXX0000 00000000 机器ID XX * XXXX XXXXXXXX 序列号 XX * 三部分进行|位或运算：如果相对应位都是0，则结果为0，否则为1 */ return ((currentMilliseconds - EPOCH) << TIMESTAMP_LEFT_SHIFT_BITS) | (getWorkerId() << WORKER_ID_LEFT_SHIFT_BITS) | sequence; } /** * 判断是否需要等待容忍时间差 */ @SneakyThrows private boolean waitTolerateTimeDifferenceIfNeed(final long currentMilliseconds) { /** * 如果获取ID时的最后一次时间毫秒数小于等于当前系统时间毫秒数，属于正常情况，则不需要等待 */ if (lastMilliseconds <= currentMilliseconds) { return false; } /** * ===>时钟回拨的情况（生成序列的时间大于当前系统的时间），需要等待时间差 */ /** * 获取ID时的最后一次毫秒数减去当前系统时间毫秒数的时间差 */ long timeDifferenceMilliseconds = lastMilliseconds - currentMilliseconds; /** * 时间差小于最大容忍时间差，即当前还在时钟回拨的时间差之内 */ Preconditions.checkState(timeDifferenceMilliseconds < getMaxTolerateTimeDifferenceMilliseconds(), "Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds", lastMilliseconds, currentMilliseconds); /** * 线程休眠时间差 */ Thread.sleep(timeDifferenceMilliseconds); return true; } // 配置的机器ID private long getWorkerId() { long result = Long.valueOf(properties.getProperty("worker.id", String.valueOf(WORKER_ID))); Preconditions.checkArgument(result >= 0L && result < WORKER_ID_MAX_VALUE); return result; } private int getMaxTolerateTimeDifferenceMilliseconds() { return Integer.valueOf(properties.getProperty("max.tolerate.time.difference.milliseconds", String.valueOf(MAX_TOLERATE_TIME_DIFFERENCE_MILLISECONDS))); } private long waitUntilNextTime(final long lastTime) { long result = timeService.getCurrentMillis(); while (result <= lastTime) { result = timeService.getCurrentMillis(); } return result; } } 但从 SNOWFLAKE 方案生成的主键ID 来看，order_id 它是一个18位的长整型数字，是不是发现它太长了，想要 MySQL 那种从 0 递增的自增主键该怎么实现呢？别急，后边已经会给出了解决办法！自定义 sharding-jdbc 利用 SPI 全称（ Service Provider Interface）机制拓展主键生成规则，这是一种服务发现机制，通过扫描项目路径 META-INF/services 下的文件，并自动加载文件里所定义的类。实现自定义主键生成器其实比较简单，只有两步。第一步，实现 ShardingKeyGenerator 接口，并重写其内部方法，其中 getType() 方法为自定义的主键生产方案类型、generateKey() 方法则是具体生成主键的规则。下面代码中用 AtomicInteger 来模拟实现一个有序自增的 ID 生成。 /** * @Author: xiaofu * @Description: 自定义主键生成器 */ @Component public class MyShardingKeyGenerator implements ShardingKeyGenerator { private final AtomicInteger count = new AtomicInteger(); /** * 自定义的生成方案类型 */ @Override public String getType() { return "XXX"; } /** * 核心方法-生成主键ID */ @Override public Comparable<?> generateKey() { return count.incrementAndGet(); } @Override public Properties getProperties() { return null; } @Override public void setProperties(Properties properties) { } } 第二步，由于是利用 SPI 机制实现功能拓展，我们要在 META-INF/services 文件中配置自定义的主键生成器类路劲。 com.xiaofu.sharding.key.MyShardingKeyGenerator 上面这些弄完我们测试一下，配置定义好的主键生成类型 XXX，并插入几条数据看看效果。 spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id spring.shardingsphere.sharding.tables.t_order.key-generator.type=XXX 通过控制台的SQL 解析日志发现，order_id 字段已按照有序自增的方式插入记录，说明配置的没问题。举一反九既然可以自定义生成方案，那么实现分布式主键的思路就很多了，又想到之前我写的这篇《9种分布式ID生成方案》，发现可以完美兼容，这里挑选其中的滴滴（Tinyid）来实践一下，由于它是个单独的分布式ID生成服务，所以要先搭建环境了。 Tinyid 的服务提供Http 和 Tinyid-client 两种接入方式，下边使用 Tinyid-client 方式快速使用，更多的细节到这篇文章里看吧，实在是介绍过太多次了。 Tinyid 服务搭建先拉源代码 https://github.com/didi/tinyid.git。由于是基于号段模式实现的分布式ID，所以依赖于数据库，要创建相应的表 tiny_id_info 、tiny_id_token 并插入默认数据。 CREATE TABLE `tiny_id_info` ( `id` BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键', `biz_type` VARCHAR (63) NOT NULL DEFAULT '' COMMENT '业务类型，唯一', `begin_id` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同', `max_id` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '当前最大id', `step` INT (11) DEFAULT '0' COMMENT '步长', `delta` INT (11) NOT NULL DEFAULT '1' COMMENT '每次id增量', `remainder` INT (11) NOT NULL DEFAULT '0' COMMENT '余数', `create_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间', `update_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间', `version` BIGINT (20) NOT NULL DEFAULT '0' COMMENT '版本号', PRIMARY KEY (`id`), UNIQUE KEY `uniq_biz_type` (`biz_type`) ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'id信息表'; CREATE TABLE `tiny_id_token` ( `id` INT (11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增id', `token` VARCHAR (255) NOT NULL DEFAULT '' COMMENT 'token', `biz_type` VARCHAR (63) NOT NULL DEFAULT '' COMMENT '此token可访问的业务类型标识', `remark` VARCHAR (255) NOT NULL DEFAULT '' COMMENT '备注', `create_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间', `update_time` TIMESTAMP NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间', PRIMARY KEY (`id`) ) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT 'token信息表'; INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`) VALUES ('1', '0f673adf80504e2eaa552f5d791b644c', 'order', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48'); INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`) VALUES ('1', 'order', '1', '1', '100000', '1', '0', '2018-07-21 23:52:58', '2018-07-22 23:19:27', '1'); 并在 Tinyid 服务中配置上边表所在数据源信息 datasource.tinyid.primary.url=jdbc:mysql://47.93.6.e:3306/ds-0?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8 datasource.tinyid.primary.username=root datasource.tinyid.primary.password=root 最后项目 maven install ，右键 TinyIdServerApplication 启动服务， Tinyid 分布式ID生成服务就搭建完毕了。自定义 Tinyid 主键类型 Tinyid 服务搭建完下边在项目中引入它，新建个 tinyid_client.properties 文件其中添加 tinyid.server 和 tinyid.token 属性，token 为之前 SQL 预先插入的用户数据。 # tinyid 分布式ID # 服务地址 tinyid.server=127.0.0.1:9999 # 业务token tinyid.token=0f673adf80504e2eaa552f5d791b644c 代码中获取 ID更简单，只需一行代码，业务类型 order 是之前 SQ L 预先插入的数据。 Long id = TinyId.nextId("order"); 我们开始自定义 Tinyid 主键生成类型的实现类 TinyIdShardingKeyGenerator 。 /** * @Author: xiaofu * @Description: 自定义主键生成器 */ @Component public class TinyIdShardingKeyGenerator implements ShardingKeyGenerator { /** * 自定义的生成方案类型 */ @Override public String getType() { return "tinyid"; } /** * 核心方法-生成主键ID */ @Override public Comparable<?> generateKey() { Long id = TinyId.nextId("order"); return id; } @Override public Properties getProperties() { return null; } @Override public void setProperties(Properties properties) { } } 并在配置文件中启用 Tinyid 主键生成类型，到此配置完毕，赶紧测试一下。 # 主键字段 spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id # 主键ID 生成方案 spring.shardingsphere.sharding.tables.t_order.key-generator.type=tinyid 测试 Tinyid 主键向数据库插入订单记录测试发现，主键ID字段 order_id 已经为趋势递增的了， Tinyid 服务成功接入，完美！总结后续的八种生成方式大家参考《9种分布式ID生成方案》按需接入吧，整体比较简单这里就不依次实现了。案例 GitHub 地址：https://github.com/chengxy-nds/Springboot-Notebook/tree/master/springboot-sharding-jdbc 整理了几百本各类技术电子书，送给小伙伴们。关注公号回复 666 自行领取。和一些小伙伴们建了一个技术交流群，一起探讨技术、分享技术资料，旨在共同学习进步，如果感兴趣就加入我们吧！

程序员内点事个人页面-阿里云开发者社区

个人介绍

擅长的技术

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

干掉 powerdesigner，设计数据库表用它就够了

千万不要给女朋友解释什么是 “羊群效应”

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

我也没想到 Springboot + Flowable 开发工作流会这么简单

又被逼着优化代码，这次我干掉了出入参 Log日志

springboot + rabbitmq 做智能家居，我也没想到会这么简单

干掉 powerdesigner，设计数据库表用它就够了

千万不要给女朋友解释什么是 “羊群效应”

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

我也没想到 Springboot + Flowable 开发工作流会这么简单

又被逼着优化代码，这次我干掉了出入参 Log日志

springboot + rabbitmq 做智能家居，我也没想到会这么简单

分享 10个我常逛的国外技术社区，真的受益匪浅！

redis 分布式锁的 5个坑，真是又大又深

一口气说出 4种 LBS “附近的人” 实现方式，面试官笑了

真没想到，Springboot能这样做全局日期格式化，有点香！

springboot + aop的最佳实践，再也不怕双击666

程序员内点事个人页面-阿里云开发者社区

个人介绍

擅长的技术

大厂也在用的 6种 数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

干掉 powerdesigner，设计数据库表用它就够了

千万不要给女朋友解释 什么是 “羊群效应”

大厂也在用的 6种 数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

我也没想到 Springboot + Flowable 开发工作流会这么简单

又被逼着优化代码，这次我干掉了出入参 Log日志

springboot + rabbitmq 做智能家居，我也没想到会这么简单

干掉 powerdesigner，设计数据库表用它就够了

千万不要给女朋友解释 什么是 “羊群效应”

大厂也在用的 6种 数据脱敏方案，严防泄露数据的 “内鬼”

看了 5种分布式事务方案，我司最终选择了 Seata，真香！

分库分表的 9种分布式主键ID 生成方案，挺全乎的

一文快速入门分库分表（必修课）

3种 Springboot 全局时间格式化方式，别再写重复代码了

我也没想到 Springboot + Flowable 开发工作流会这么简单

又被逼着优化代码，这次我干掉了出入参 Log日志

springboot + rabbitmq 做智能家居，我也没想到会这么简单

分享 10个我常逛的国外技术社区，真的受益匪浅！

redis 分布式锁的 5个坑，真是又大又深

一口气说出 4种 LBS “附近的人” 实现方式，面试官笑了

真没想到，Springboot能这样做全局日期格式化，有点香！

springboot + aop的最佳实践，再也不怕双击666

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”

千万不要给女朋友解释什么是 “羊群效应”

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”

千万不要给女朋友解释什么是 “羊群效应”

大厂也在用的 6种数据脱敏方案，严防泄露数据的 “内鬼”