分布式事务保姆级教程
⼀、本地事务
1、ACID特性
原⼦性(A)⼀致性(C)隔离性(I)持久性(D)
2、事务的隔离级别
两个或多个事务并发操作相同的数据的时候事务之间的相互访问关系
- 查询当前隔离级别：select @@tx_isolation
- 设置隔离级别：set session transaction isolation level 隔离级别
- 开启事务：start transaction
- 提交事务：commit
- 事务回滚：rollaback
⼆、分布式事务
分布式事务：就是指事务的参与者、⽀持事务的服务器（数据库服务器）、资源服务器以及事务的管理器分布在分布式系统的不同节点中
1、分布式事务场景
2、分布式事务 & 分布式锁
分布式事务：完成事务的多个步骤位于不同的节点上分布式锁：⽤于解决分布式系统中事务之间的并发访问问题
三、CAP定律和BASE理论
分布式系统设计中的CAP定律和base理论
1、CAP定律
1、CAP原则⼜称CAP定律，指的是在⼀个分布式系统中的⼀致性（Consistency）、可⽤性（Availability）、分区容错性三者之间的权衡
2、CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾
- 在分布式系统⽆法同时满⾜CA，如果需要满⾜CA，则项⽬结构必须为单体架构
- 在分布式系统中可以满⾜CP 或者 AP，常规情况下微服务架构更多的是满⾜AP
1、（强）⼀致性(Consistency) ：如果系统对⼀个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果写操作返回失败，则所有的读操作都不能读到这个数据，对调⽤者⽽⾔数据具有强⼀致性。
- 强⼀致性：⼀旦写操作成功了，则所有的读操作都必须读取新数据；（如果想要保证数据的强⼀致性，就必须使⽤同⼀个数据存储/数据库）
- 弱⼀致性/最终⼀致性：当写操作成功之后，允许在⼀定的时间内读取到旧数据，但经过⼀段时间之后最终可以读取到新数据，保证数据最终是⼀致的
2、可⽤性(Availability) ：当⽤户请求服务时，服务⼀定要给与响应，可以是降级响应。3、分区容错性(Partition tolerance) ：在分布式系统中服务节点都是⽹络分布，⼀个或部分节点出现故障，其他节点仍能对外提供服务。
2、BASE理论
1、BASE是Basically Available(基本可⽤)，Soft State（软状态）和EventuallyConsistent（最终⼀致性）三个短语的缩写。2、BASE理论，是对CAP中⼀致性和可⽤性权衡的结果，其来源于对⼤规模互联⽹分布式系统实践的总结，是基于CAP定律逐步演化⽽来。其核⼼思想是即使⽆法做到强⼀致性，但每个应⽤都可以根据⾃身业务特点，采⽤适当的⽅式来使系统达到最终⼀致性。
1、基本可⽤：指的是分布式系统中出现不可预知故障，允许其损失⼀部分的功能，但要保证整个系统的可⽤。
2、软状态：允许系统中数据存在中间状态，这个中间状态不会影响系统的可⽤性；也就是允许不同节点的数据副本之间在数据同步过程中存在延时。
3、最终⼀致性：要求所有的数据副本在经过⼀段时间的延时之后，最终能够达到⼀致的状态。
四、分布式事务解决⽅案
1、刚性事务与柔性事务
1、刚性事务：满⾜ACID特性的事务（强⼀致性）————本地事务2、柔性事务：满⾜BASE理论的事务（最终⼀致性）————分布式事务3、如何保证分布式事务的最终⼀致性？
- XA-2PC
- 补偿
- 异步确保
- 最⼤努⼒通知
2、XA-分布式事务管理模型
XA模型—为分布式事务的多个参与者添加到⼀个事务管理器(事务协调者)
3、2PC—两段式提交
问题：1.性能问题：所有事务的参与者在提交阶段处于阻塞状态，占⽤系统资源（数据库连接）2.可靠性问题：如果事务协调者出现单点故障，将导致所有的参与者都处于锁定状态3.数据⼀致性问题：事务协调者和部分参与者在事务提交阶段挂了，有可能导致数据⼀致性问题优点：近乎100%的保证了数据的⼀致性缺点：实现复杂，牺牲了可⽤性，对性能影响⽐较⼤；适⽤于并发不⾼但是对数据⼀致性要求⽐较⾼的场景。
4、3PC—三段式提交
三段式提交就是在两段式提交进⾏改进的版本：
- 增了⼀个资源检查阶段（询问是否可以提交）
- 增加了超时设置——避免因TM故障导致TC⻓时间等待占⽤系统资源
存在的问题：和2PC提交⼀样，执⾏SQL之后需要保持数据库连接，影响系统性能
5、TCC
TCC, 即Try-Commit-Cancel
优点：1.性能提升：资源占⽤的粒度较⼩，不会⻓时间锁定所有资源2.数据的最终⼀致性：基于commit和cancel的幂等性
6、消息队列
五、分布式事务框架 Tx-LCN
3PC——适⽤于对数据⼀致性要求较⾼的场景，对性能会有⼀定损耗TCC——性能优于3PC，但是不能保证数据的强⼀致性，可以保证最终⼀致性
基于3PC、TCC等分布式事务解决⽅案已经有成熟的落地框架：
- zookeeper
- Tx-LCN
- Spring Cloud alibaba seata
LCN模式是通过代理Connection⽅式实现对本地事务的操作，然后由TxManager统⼀协调管理
1、⼯作流程
2、TxLCN⽀持的分布式事务管理⽅式
1、@LcnTransaction lcn模式LCN模式是通过代理Connection的⽅式实现对本地事务的操作，然后在由TxManager统⼀协调控制事务。当本地 事务提交回滚或者关闭连接时将会执⾏假操作，该代理的连接将由LCN连接池管理。2、@TxcTransaction txc模式TXC模式命名来源于淘宝，实现原理是在执⾏SQL之前，先查询SQL的影响数据，然后保存执⾏的SQL快照信息和 创建锁。当需要回滚的时候就采⽤这些记录数据回滚数据库，⽬前锁实现依赖redis分布式锁控制。3、@TccTransaction tcc模式TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA 的⽀持，⽽是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执⾏业务、 Confirm:确认执⾏业务、 Cancel: 取消执⾏业务。
六、搭建TM服务器
1、按照TM的要求建库建表
CREATE TABLE `t_tx_exception` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `group_id` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `unit_id` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `mod_id` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL, `transaction_state` tinyint(4) NULL DEFAULT NULL, `registrar` tinyint(4) NULL DEFAULT NULL, `ex_state` tinyint(4) NULL DEFAULT NULL COMMENT '0 待处理 1已处理', `remark` varchar(10240) NULL DEFAULT NULL COMMENT '备注', `create_time` datetime(0) NULL DEFAULT NULL, PRIMARY KEY (`id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 967 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic; SET FOREIGN_KEY_CHECKS = 1;
2、配置并启动redis
3、创建SpringBoot项⽬
4、导⼊tm依赖
<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.47</version> </dependency> <dependency> <groupId>com.codingapi.txlcn</groupId> <artifactId>txlcn-tm</artifactId> <version>5.0.2.RELEASE</version> </dependency>
5、配置application.properties(官⽅说明⽂档提供)
spring.application.name=TransactionManager server.port=8801 # JDBC 数据库配置 spring.datasource.driver-class-name=com.mysql.jdbc.Driver spring.datasource.url=jdbc:mysql://47.96.11.185:3306/fmmall2?characterEncoding=UTF-8&serverTimeZone=UTC spring.datasource.username=root spring.datasource.password=admin123 # 数据库⽅⾔ spring.jpa.database-platform=org.hibernate.dialect.MySQL57Dialect # 为TM创建持久化数据库表 spring.jpa.hibernate.ddl-auto=update # TM监听Socket端⼝. 默认为 ${server.port} - 100 tx-lcn.manager.port=8070 # TM后台登陆密码，默认值为codingapi tx-lcn.manager.admin-key=admin123 # 雪花算法的sequence位⻓度，默认为12位. tx-lcn.manager.seq-len=12 # 异常回调开关。开启时请制定ex-url tx-lcn.manager.ex-url-enabled=false # 开启⽇志,默认为false tx-lcn.logger.enabled=true tx-lcn.logger.driver-class-name=${spring.datasource.driver-classname} tx-lcn.logger.jdbc-url=${spring.datasource.url} tx-lcn.logger.username=${spring.datasource.username} tx-lcn.logger.password=${spring.datasource.password} # redis 的设置信息. 线上请⽤Redis Cluster spring.redis.host=47.96.11.185 spring.redis.port=6379 spring.redis.password=12345678
6、启动类添加 @EnableTransactionManagerServer 注解
@SpringBootApplication @EnableTransactionManagerServer public class TxmanagerApplication { public static void main(String[] args) { SpringApplication.run(TxmanagerApplication.class, args); } }
7、启动项⽬，访问8801，出现如下界⾯（使⽤设置的密码登录）
七、在服务中添加分布式事务⽀持
1、添加TC依赖
<dependency> <groupId>com.codingapi.txlcn</groupId> <artifactId>txlcn-tc</artifactId> <version>5.0.2.RELEASE</version> </dependency> <dependency> <groupId>com.codingapi.txlcn</groupId> <artifactId>txlcn-txmsg-netty</artifactId> <version>5.0.2.RELEASE</version> </dependency>
2、配置服务链接到TM
spring: datasource: null driver-class-name: com.mysql.jdbc.Driver url: 'jdbc:mysql://localhost:3306/fmmall2?characterEncoding=utf-8' username: root password: admin123 tx-lcn: client: null manager-address: 'localhost:8070'
3、在启动类添加 @EnableDistributedTransaction 注解
4、添加分布式事务管理注解
@TccTransaction @Transactional public void addOrder(Order order) { orderDAO.insertOrder(order); ResultVO vo = repoInvokeService.update(order.getGid(), 1); System.out.println(vo); }
1、@LcnTransaction lcn模式LCN模式是通过代理Connection的⽅式实现对本地事务的操作，然后在由TxManager统⼀协调控制事务。当本地 事务提交回滚或者关闭连接时将会执⾏假操作，该代理的连接将由LCN连接池管理。2、@TxcTransaction txc模式TXC模式命名来源于淘宝，实现原理是在执⾏SQL之前，先查询SQL的影响数据，然后保存执⾏的SQL快⾛信息和 创建锁。当需要回滚的时候就采⽤这些记录数据回滚数据库，⽬前锁实现依赖redis分布式锁控制。3、@TccTransaction tcc模式TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA 的⽀持，⽽是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执⾏业务、Confirm:确认执⾏业务、 Cancel: 取消执⾏业务。
