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

目录

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

一、写在前面

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

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

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

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

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

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

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

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

阿里面试官就是厉害,居然问我分布式事务怎么实现高可用?_第1张图片

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


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

1、上游服务投递消息

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

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

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

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

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

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

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

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

啥意思呢?

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

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

你可能感兴趣的:(面试求职,分布式,Java,分布式,java,数据库)