Java互联网架构-深入理解MQ实现分布式事务

Java小马哥 2017-10-22 22:20

概述

分布式系统（distributedsystem）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。

透明性是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。

在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。

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

强一致

当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 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支持事务就好，其实在分布式事务这一块还有一种最大努力型，也比较无脑的一种方式。

总结

到这里，MQ实现分布式事务就结束了，，不足之处还望大家多多包涵！！觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持。（吹一波，233~~）

下面和大家交流几点编程的经验：

1、多写多敲代码，好的代码与扎实的基础知识一定是实践出来的

2丶 测试、测试再测试，如果你不彻底测试自己的代码，那恐怕你开发的就不只是代码，可能还会声名狼藉。

3丶 简化编程，加快速度，代码风骚，在你完成编码后，应回头并且优化它。从长远来看，这里或那里一些的改进，会让后来的支持人员更加轻松。

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步。

内部交流群469717771 欢迎各位前来交流和分享， 验证：（007）

Java小马哥，头条出品，每天一篇干货，喜欢就收藏＋关注