阿里面试官就是厉害，居然问我分布式事务怎么实现高可用？

目录

• 一、写在前面
• 二、可靠消息最终一致性方案的核心流程
• 三、可靠消息最终一致性方案的高可用保障生产实践

一、写在前面

上一篇文章咱们聊了聊TCC分布式事务，对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。

这个时候，用TCC分布式事务方案来保证各个接口的调用，要么一起成功，要么一起回滚，是比较合适的。

但是在实际系统的开发过程中，可能服务间的调用是异步的。

也就是说，一个服务发送一个消息给MQ，即消息中间件，比如RocketMQ、RabbitMQ、Kafka、ActiveMQ等等。

然后，另外一个服务从MQ消费到一条消息后进行处理。这就成了基于MQ的异步调用了。

那么针对这种基于MQ的异步调用，如何保证各个服务间的分布式事务呢？

也就是说，我希望的是基于MQ实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败。

这个时候，就要用上可靠消息最终一致性方案，来实现分布式事务。

大家看看上面那个图，其实如果不考虑各种高并发、高可用等技术挑战的话，单从“可靠消息”以及“最终一致性”两个角度来考虑，这种分布式事务方案还是比较简单的。

---

二、可靠消息最终一致性方案的核心流程

1、上游服务投递消息

如果要实现可靠消息最终一致性方案，一般你可以自己写一个可靠消息服务，实现一些业务逻辑。

首先，上游服务需要发送一条消息给可靠消息服务。

这条消息说白了，你可以认为是对下游服务一个接口的调用，里面包含了对应的一些请求参数。

然后，可靠消息服务就得把这条消息存储到自己的数据库里去，状态为“待确认”。

接着，上游服务就可以执行自己本地的数据库操作，根据自己的执行结果，再次调用可靠消息服务的接口。

如果本地数据库操作执行成功了，那么就找可靠消息服务确认那条消息。如果本地数据库操作失败了，那么就找可靠消息服务删除那条消息。

此时如果是确认消息，那么可靠消息服务就把数据库里的消息状态更新为“已发送”，同时将消息发送给MQ。

这里有一个很关键的点，就是更新数据库里的消息状态和投递消息到MQ。这俩操作，你得放在一个方法里，而且得开启本地事务。

啥意思呢？

• 如果数据库里更新消息的状态失败了，那么就抛异常退出了，就别投递到MQ；

• 如果投递MQ失败报错了，那么就要抛异常让本地数据库事务回滚。