微服务-分布式事务解决方案

Posted 2021-11-29 ricklz

微服务的搭建

微服务中我们把业务的能力进行了抽象，实际的业务中我们需要用到不同的服务的能力，并且我们处理的业务需要事务的一致性，避免出现数据的紊乱，那么我们就需要对分布式的微服务进行一致性事务的处理。下面是我自己总结的几种方案。

分布式事务解决的方案

一、（XA）两阶段方案

1、先提交每一个（这个是加锁）

2、确认资源，确认每一个RM是否都成功了，判断是否要提交还是要回滚

二、TCC（try-confirm-cancle）两阶段补偿性方案

1、先提交状态为中间状态（数据表更改为更新中，而不是加锁）

2、确认资源，确认每一个RM是否都成功了，都成功了，更新sql的状态，否则回滚

TCC相比于XA的优点

1、TCC是更新数据为中间状态，而两阶段方案是加锁

2、TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放，例如，假设有AB 两个操作，假设A操作耗时短，那么A就能较快的完成自身的try-confirm-cancel流程，释 放资源，无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可

3、TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作)，也就是各服务之间可以 在一定程度上”异步并行”执行

适用的场景：

1、严格一致性

2、执行时间短

3、实时性要求高

三、异步确认性

通过将一系列同步的事务操作变为基于消息执行异步操作，避免了分布式事务中的同步阻塞 操作的影响。

需要额外说明的一点，就是事务消息投递到MQ定阅方后，并不一定能够成功执行。

需要 MQ订阅方主动给予消费反馈（ack）:

1、如果MQ订阅方执行远程事务成功，则给予消费成功的ACK,那么MQ server可以将事务 消息移除；

2、如果执行失败，MQ Server需要对消息重新投递，直至消费成功。

注意事项

1、消息中间件在系统中扮演一个重要的角色，所有的事务消息都需要通过它来传达，所以 消息中间件也需要支持 HAC 来确保事务消息不丢失。

2、根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复，不乱序等其 它要求。

适用场景

1、执行周期较长

2、实时行要求不高

例如

1、跨行转账/汇款业务（两个服务分别在不同的银行中）

2、退货/退款业务

3、财务，账单统计业务（先发送到消息中间件，然后进行批量记账）

四、最大努力通知型

这是分布式事务中要求最低的一种，也可以通过消息中间件实现，与前面异步确保型操作不 同的一点是，在消息由MQ Server投递到消费者之后，允许在达到最大重试次数之后正常 结束事务。

适用场景

交易结果消息的通知等。