聊聊分布式事务的解决方案

在一个分布式微服务系统中，由于每个微服务可能都有自己的数据库，例如支付宝给余额宝转账

怎么确保两边的操作都成功？

常用的解决方案有以下几种：

1，基于XA协议的2PC（两阶段提交）

两阶段提交，其实就是有一个全局的事务管理器管理。
第一阶段：各微服务数据库预提交此事务操作，并反馈是否可以提交给事务协调器，及投票

第二阶段:根据数据库投票结果要求提交或者回滚。

这种方式实现难度不大，适合传统项目中偶尔需要的在同一个方法中操作不同数据库的场景，由于每一次事务操作需要涉及到系统间的多次通信协调，所以最大的缺陷是性能不好。不适合高并发的场景。

具体的两阶段提交的实现：

根据用于管理事务的底层实现，Spring中的事务策略可以分为两个主要部分：

单连接器策略（相当于本地事务管理器） - 底层技术使用单连接器。例如，JDBC使用连接级事务、Hibernate以及JDO使用会话级事务。可以应用使用AOP和拦截器的声明式事务管理。

多连接器策略（相当于全局事务管理器） - 底层技术具有使用多个连接器的能力。当有这方面需求时，JTA是最好的选择。此策略需要启用JTA的数据源实例。JBossTS、Atomikos、Bitronix都是开源的JTA实现。
————————————————
spring JTA分布式事务实现见下文。JTA事务管理器采用Bitronix。
JTA的真正强大之处在于它能够在单个事务中管理多个资源（如数据库，消息服务）。
具体步骤为
1.1 pom中加jta依赖

org.springframework.boot
spring-boot-starter-jta-bitronix

1.2 在服务启动时建立两个或者多个数据源（加入bitronix管理）

@Bean(“dataSourceAccount”)
public DataSource dataSource() throws Exception {
return createHsqlXADatasource(“jdbc:hsqldb:mem:accountDb”);
}

@Bean(“dataSourceAudit”)
public DataSource dataSourceAudit() throws Exception {
return createHsqlXADatasource(“jdbc:hsqldb:mem:auditDb”);
}

1.3 在方法中加入@Transactional注解
@Transactional
public void executeTransfer(String fromAccontId, String toAccountId,
BigDecimal amount) {
bankAccountService.transfer(fromAccontId, toAccountId, amount);
auditService.log(fromAccontId, toAccountId, amount);
BigDecimal balance = bankAccountService.balanceOf(fromAccontId);
if (balance.compareTo(BigDecimal.ZERO) < 0) {
throw new RuntimeException(“余额不足!”);
}
}

详细参考以下链接：
https://blog.csdn.net/peterwanghao/article/details/100076076

2，消息中间件加事件表（常用）

简单的来说就是支付宝扣钱之后，存放一个让余额宝加钱的消息到消息队列中，余额宝一旦接收到此消息后就操作数据库加钱。
那么存在的问题就是，怎么保证支付宝从自己数据库扣钱跟消息存放到消息中间件这两个操作的原子性？万一支付宝扣完钱之后服务宕机了怎么办？还有拿到消息后准备消费时服务宕机了怎么办？
那么就需要一个事件表加定时任务来维持原子性。

支付宝扣完钱后更新事件表（状态刷为new）（加事务保证原子性），定时任务遍历事件表处理新消息，负责把消息存到消息中间件里面，存放成功后更新事件表状态为publish。
余额宝从消息中间件里面取出消息然后刷新事件表（新增一条记录，状态为publish，加事务保证原子性），定时任务遍历事件表处理publish状态的任务，处理完后更新状态为finish，并通知broker从队列中删除消息。

3，异步校验数据
比对两个数据库表，根据差异做一些业务处理。

下面这篇文章写得也不错。
http://developer.51cto.com/art/201808/581174.htm