分布式事务(3)---RocketMQ实现分布式事务原理

分布式事务(3)—RocketMQ实现分布式事务原理

以前讲过有关分布式事务2PC、3PC、TCC的理论知识,博客地址：

一、分布式事务(1)---2PC和3PC原理

二、分布式事务(2）---TCC原理

这篇讲有关RocketMQ实现分布式事务的理论知识，下篇也会示例 经过SpringCloud来实例RocketMQ实现分布式事务的项目。

1、举个分布式事务场景

列子：假设 A 给 B 转 100块钱，同时它们不是同一个服务上。

目标：就是 A 减100块钱，B 加100块钱。

实际状况可能有四种：

1）就是A帐户减100 （成功），B帐户加100 （成功）

2）就是A帐户减100（失败），B帐户加100 （失败）

3）就是A帐户减100（成功），B帐户加100 （失败）

4）就是A帐户减100 （失败），B帐户加100 （成功）

这里 第1和第2 种状况是可以保证事务的一致性的，可是 第3和第4 是没法保证事务的一致性的。

那咱们来看下RocketMQ是如何来保证事务的一致性的。

2、RocketMQ实现分布式事务原理

RocketMQ虽然以前也支持分布式事务，但并无开源，等到RocketMQ 4.3才正式开源。

一、基础概念

最终一致性

RocketMQ是一种最终一致性的分布式事务，就是说它保证的是消息最终一致性，而不是像2PC、3PC、TCC那样强一致分布式事务，至于为何说它是最终一致性事务下面会详细说明。

Half Message(半消息)

是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息。须要 Producer

对消息的二次确认后，Consumer才能去消费它。

消息回查

因为网络闪段，生产者应用重启等缘由。致使 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这是Brock服务器会定时扫描长期处于半消息的消息，会

主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

二、分布式事务交互流程

理解这张阿里官方的图，就能理解RocketMQ分布式事务的原理了。

咱们来讲明下上面这张图

一、A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。

二、当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。

三、执行本地事务(会有三种状况一、执行成功。二、执行失败。三、网络等缘由致使没有响应)

4.1)、若是本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就能够消费该message。

4.2)、若是本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。

4.3)、若是由于网络等缘由迟迟没有返回失败仍是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。

从上面流程能够得知 只有A服务本地事务执行成功 ，B服务才能消费该message。

而后咱们再来思考几个问题？

为何要先发送Half Message(半消息)

我以为主要有两点

1）能够先确认 Brock服务器是否正常 ，若是半消息都发送失败了 那说明Brock挂了。

2）能够经过半消息来回查事务，若是半消息发送成功后一直没有被二次确认，那么就会回查事务状态。

什么状况会回查

也会有两种状况

1）执行本地事务的时候，因为忽然网络等缘由一直没有返回执行事务的结果(commit或者rollback)致使最终返回UNKNOW，那么就会回查。

2) 本地事务执行成功后，返回Commit进行消息二次确认的时候的服务挂了，在重启服务那么这个时候在brock端
   它仍是个Half Message(半消息)，这也会回查。

特别注意: 若是回查，那么必定要先查看当前事务的执行状况，再看是否须要从新执行本地事务。

想象下若是出现第二种状况而引发的回查，若是不先查看当前事务的执行状况，而是直接执行事务，那么就至关于成功执行了两个本地事务。

为何说MQ是最终一致性事务

经过上面这幅图，咱们能够看出，在上面举例事务不一致的两种状况中，永远不会发生

A帐户减100 （失败），B帐户加100 （成功）

由于：若是A服务本地事务都失败了，那B服务永远不会执行任何操做，由于消息压根就不会传到B服务。

那么 A帐户减100 （成功），B帐户加100 （失败） 会不会可能存在的。

答案是会的

由于A服务只负责当我消息执行成功了，保证消息可以送达到B,至于B服务接到消息后最终执行结果A并无论。

那B服务失败怎么办？

若是B最终执行失败，几乎能够判定就是代码有问题因此才引发的异常，由于消费端RocketMQ有重试机制，若是不是代码问题通常重试几回就能成功。

若是是代码的缘由引发屡次重试失败后，也没有关系，将该异常记录下来，由人工处理，人工兜底处理后，就可让事务达到最终的一致性。

只要本身变优秀了，其余的事情才会跟着好起来（上将7）