分布式事务之最终一致的Mq实现

问题的起源

分布式系统的特性

对分布式系统有过研究的读者,可能听说过“CAP定律”、“Base理论”等,非常巧的是,化学理论中ACID是酸、Base恰好是碱。这里我们不对这些概念做过多的解释,有兴趣的读者可以查看相关参考资料。

这里针对一致性我们做个简单的科普:

分布式事务有强一致,弱一致,和最终一致性这三种:

强一致

当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。根据 CAP 理论,这种实现需要牺牲可用性。

弱一致

系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到。

最终一致

弱一致性的特定形式。系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值。在没有故障发生的前提下,不一致窗口的时间主要受通信延迟,系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统

在分布式系统中,同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是几乎不可能的。在互联网领域的绝大多数的场景,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可,这时候我们只需要用短暂的数据不一致就可以达到我们想要效果。

实例描述

比如有订单,库存两个数据,一个下单过程简化为,加一个订单,减一个库存。 而订单和库存是独立的服务,那怎么保证数据一致性。

这时候我们需要思考一下,怎么保证两个远程调用“同时成功”,数据一致?

请大家先注意一点远程调用最郁闷的地方就是,结果有3种,成功、失败和超时。 超时的话,成功失败都有可能。

一般的解决方案,大多数的做法是借助mq来做最终一致。

如何实现最终一致

实例分析

我们是怎么利用Mq来达到最终一致的呢?下面让我们来一起进行详细的分析:

订单业务分析

首先,拿我们上面提到的订单业务举例:

  • 在我们进行加订单的过程中同时插入logA(这个过程是可以做本地事务的)
  • 然后可以异步读取logA,发mqA
  • B端接收mqA,同时减少库存,B这里需要做幂等(避免因为重复消息造成的业务错乱)

复杂的混合异步业务调用

那么我们通过上面的分析可能联想到这样的问题?

本地先执行事务,执行成功了就发个消息过去,消费端拿到消息执行自己的事务 比如a,b,c a异步调用b,c, 如果b失败了,或者b成功,或者b超时,那么怎么用mq让他们最终一致呢?b失败就失败了,b成功之后给c发一个消息,b和c对a来讲都是异步的,且他们都是同时进行的话,而且需要a,b,c同时成功的情况,那么这种情况用mq怎么做

其实做法还是参照于本地事务的概念的。

  • 第一种情况:假设a,b,c三者都正常执行,那整个业务正常结束
  • 第二种情况:假设b超时,那么需要a给b重发消息(记得b服务要做幂等),如果出现重发失败的话,需要看情况,是终端服务,还是继续重发,甚至人为干预(所有的规则制定都需要根据业务规则来定)
  • 第三种情况:假设a,b,c三者之中的一个失败了,失败的服务利用MQ给其他的服务发送消息,其他的服务接收消息,查询本地事务记录日志,如果本地也失败,删除收到的消息(表示消息消费成功),如果本地成功的话,则需要调用补偿接口进行补偿(需要每个服务都提供业务补偿接口)。

注意事项

mq这里有个坑,通常只适用于只允许第一个操作失败的场景,也就是第一个成功之后必须保证后面的操作在业务上没障碍,不然后面失败了前面不好回滚,只允许系统异常的失败,不允许业务上的失败,通常业务上失败一次后面基本上也不太可能成功了,要是因为网络或宕机引起的失败可以通过重试解决,如果业务异常,那就只能发消息给a和c让他们做补偿了吧?通常是通过第三方进行补偿,ABC提供补偿接口,设计范式里通常不允许消费下游业务失败

上面的话我们该怎么理解呢,举个例子吧

比如A给B转账,A先自己扣钱,然后发了个消息,B这边如果在这之前销户了,那重试多少次也没用,只能人工干预

阿里在分布式事务采用的解决方式

阿里部分业务是用Mq实现了最终一致性,也有一部分业务用了tcc事务,但是tcc事务用的比较少,因为会侵染业务,开发成本比较高,如果体量不大的话直接用jta或mq支持事务就好,其实在分布式事务这一块还有一种最大努力型,也比较无脑的一种方式。

声明

以上观点均为个人总结,不代表完全正确。

Loading Disqus comments...
Table of Contents