分布式事务 一、概述指事务的操作位于不同的节点上，需要保证事务的ACID原则，如：订单与库存不在同一个节点上，但需要保证两个事务的一致性（下单—减少库存，取消订单—库存恢复）二、实现分布式事务的方式1、两段提交（2PC）需要数据库厂商的支持，java组件有atomikos等两阶段提交（Two-phase Commit），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务准备阶段协调者询问参与者事务是否执行成功，参与者返执行回结果提交阶段如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则反之，即回滚事务注：参与者在准备阶段执行成功，但未提交事务，只有在提交阶段收到协调者的消息，才会执行提交或回滚存在的问题1、同步阻塞，所有参与者在等待其他参与者相应的时候都处于同步阻塞状态，无法进行其他操作2、单点问题，协调者在2PC中起到非常大的作用，产生故障时影响也非常大3、数据不一致，在阶段二，如果协调者只发送了部分Commit消息，此时如果产生网络异常，则只有接收到Commit消息的参与者提交了事务，使得数据不一致4、任意一个节点失败，就会导致整个事务失败，容错机制不完善2、补偿事务（TCC）针对每个操作，都注册一个与其对应的确认和补偿（撤销）操作，分为三个阶段：Try 对业务系统做检测及资源预留Confirm 对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的（只要Try成功，Confirm一定成功）Cancel 在业务执行错误，需要回滚时执行业务的取消，释放预留资源优缺点实现流程相较于2PC简单，但数据一致性比2PC要更差一些TCC属于应用层的一种补偿方式，所以在实现业务的时候需要编写很多的补偿代码，在一些业务场景中，业务处理不太友好3、本地消息表（异步确保）本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用消息队列保证最终一致性。在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中之后将本地消息表的消息转发到Kafka等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作优缺点1、避免了分布式事务，实现数据一致性2、消息表会耦合到业务系统中，耦合度太高4、MQ事务消息一些第三方的MQ是支持事务消息的，如RocketMQ，它们支持事务的方式类似于二阶段提交，流程大致为：第一阶段：Prepared消息，拿到消息的地址；第二阶段：执行本地事务；第三阶段：通过第一阶段拿到的地址去访问消息，并修改状态也就是说在业务方法内要让消息队列提交两次请求，一次发送消息，一次确认消息。如果确认消息发送失败了，RabbitMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RabbitMQ会根据发送端设置的策略来决定回滚还是继续发送确认消息，这样就保证了消息发送与本地事务同时成功或同时失败优缺点1、实现最终一致性，不需要依赖本地数据库事务2、实现难度大，主流MQ不支持