分布式事务实现的几种思路

分布式事务概念

在java项目中经常需要使用到事务，一个事务通常代表一个流程，一个连续性的数据变化。如果其中某一环出现问题，那么就需要将这段在数据库中进行的所有操作进行回退。而我们为了提高服务器的并发和稳定，开始使用分布式微服务，其中也不乏需要使用到事务的场景，在不同的微服务之间会进行同一个事务操作，也就是我们需要学习到的分布式事务了。

分布式事务实现的几种思路

实现分布式事务有几种思路，本地消息表、消息队列

1、本地消息表

服务器A在写入本地数据库的时候，利用本地事务写入业务数据表和本地消息表，然后将本地消息表中的消息发送给MQ中，服务器B从MQ中读取消息，然后写入数据库，再修改服务器A中的消息状态。

2、MQ 事务消息

利用MQ的事务消息实现分布式事务，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。RocketMQ实现事务消息的方式，从消息提交到消息确认之间，添加了half消息的状态，需要本地第二次确定才会发出确认状态的消息。

3、TCC

TCC分为三个阶段，T：try 主要是针对业务系统做检测和准备。C：confirm 确认业务系统没有报错，只要try阶段成功执行，默认confirm阶段成功，所以confirm阶段主要是针对业务系统中的报错，对其进行撤销。C：cancel 业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。TCC中最关键的便是针对每一步操作都需要进行补偿性的操作，即在业务执行错误的时候，对数据进行回滚的操作。要大量的代码投入，无疑增加了系统的复杂度。

4、两阶段提交（2PC）

提出了事务协调者这一层作为校验机制，所有参与者需要接受到协调者的消息并且执行事务，如果所有参与者都执行成功并向协调者发送确认状态，协调者发出确认状态后参与者才会提交事务。需要注意的是在参与者接受协调者消息后，没有接收到协调者的确认消息时，不会提交事务。缺点非常明显，需要协调者高可用性，且如果有一个参与者报错，没有发送确认状态，那么所有参与者都需要回滚事务，过于保守，效率较低。