初学分布式事物

最新推荐文章于 2022-08-29 14:59:56 发布

码农爱java

最新推荐文章于 2022-08-29 14:59:56 发布

阅读量146

点赞数

文章标签：分布式事务

本文链接：https://blog.csdn.net/weixin_42118323/article/details/88580555

版权

事物特性(ACID)
原子性：在一个事务中的操作，要么成功，要么失败，没有中间状态，发生异常，回滚所有操作；
一致性：事务必须保证系统的一致性（转账的例子，A少了500，B一定多了500块）
隔离性：事务与事务之间是相互隔离的，不会影响，一个事物也不会被另外一个事物打断
持久性：事务完成后，事务对数据库做的所有操作，完整的保存在数据库中，永远不会改变，不能回滚
事务并发问题：
脏读：事务A读取了事务B更新的数据，然后事务B 回滚，事务A读取的是脏数据
不可重复读：事务A多次读取同一数据，事务B在事务A的读取过程中，对数据进行了更新并提交，导致事务A 多次读取的事务不一致
幻读：A事务对数据库某个字段进行了修改，这个时候事务B 新增了一条数据，A事务发现还有一条记录没有修改，就是幻读
小结：不可重复读和幻读侧重的点不一样，不可重复读侧重于修改，幻读侧重于新增和删除，解决不可重复读只需要锁住满足条件的行，解决幻读需要锁表。
mysql 事务隔离级别
读未提交（read-uncommitted）
读已提交（read-committed）–oracle 默认事务隔离级别
可重复读（repeatable-read）–mysql 默认事务隔离级别
串行化（serializable）
分布式事务解决方案
1）两阶段提交（2PC）
准备阶段：所有参与事务的执行者准备执行事务并锁住资源。并想transaction manger 汇报自己已经准备好
提交阶段：当transaction manger 确认所有参与者都ready 后，向所有参与者发送commit命令
优点：尽量保证了数据的一致性，适合对数据强一直性要求高的领域。
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发场景。
2）补偿事务（TCC）
TCC 采用的是补偿机制，核心思想就是对每个操作，都要注册一个与其对应的确认和补偿（撤销操作），他分为三个阶段
Try 阶段：主要是对业务系统做检测和资源预留(简单理解：把要操作的资源冻结)
Confirm：主要是业务系统的操作进行确认提交，Try阶段成功则Confirm 阶段默认成功
Cancel：主要在业务执行错误，需要回滚的情况下执行的业务取消，预留资源释放
优点：可以让应用自己操作数据库的颗粒度，降低锁冲突
缺点：对应用的侵入性强，每个业务逻辑分支都要执行 Try Confirm Cancel 操作，改造成本高；实现难度较大，需要根据不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必选实现幂等
3）本地消息表（异步确认）
消息生产者：生产者需要额外建一个消息表，记录消息发送状态，消息表和业务数据要在一个事务中提交。然后消息会发送给消费者，发送失败话，会重复发送
消息消费者：处理接受到的消息，完成自己的业务逻辑。如果本地处理成功，那就表明处理成功了，如果处理失败，那就会重新执行，如果是业务上的失败，可以给生产者发送一个补偿消息通知其回滚
优点：避免了分布式事务，实现了最终一致性
缺点：消息表会耦合到，业务系统中，如果没有封装好的方案，可能有很多杂活处理。
4）MQ 事务
有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。
```
 	以阿里的 RocketMQ 中间件为例，其思路大致为：

 	第一阶段Prepared消息，会拿到消息的地址。
 	第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

 	也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
 5）GTS--分布式事务解决方案
 	 性能超强：GTS通过大量创新，解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。
 	应用侵入性极低：GTS对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。
 	完整解决方案：GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。
    容错能力强：GTS解决了XA事务协调器单点问题，实现真正的高可用，可以保证各种异常情况下的严格数据一致。
```