Before talked about theoretical knowledge about distributed transactions 2PC, 3PC, TCC, the blog address:
1, distributed transactions (1) --- 2PC and 3PC principle
2, distributed transactions (2) --- TCC principle
This speaks theoretical knowledge about RocketMQ achieve a distributed transaction, the next project will be an example to instantiate RocketMQ implement distributed transactions through SpringCloud.
First, give the scene a distributed transaction
列子: Suppose A to B switch 100 dollars , while they are not on the same service.
目标: Is A minus 100 dollars, B plus 100 dollars.
The actual situation may be, there are four:
1）就是A账户减100 （成功），B账户加100 （成功）
2）就是A账户减100（失败），B账户加100 （失败）
3）就是A账户减100（成功），B账户加100 （失败）
4）就是A账户减100 （失败），B账户加100 （成功）
Here the first and second case is to ensure the consistency of the transaction, but third and fourth is not guaranteed consistency of affairs.
That is how we look at RocketMQ to ensure the consistency of the transaction.
Two, RocketMQ implement the principle of distributed transactions
RocketMQ also supports distributed transactions before though, but did not open until RocketMQ 4.3 was officially open.
1, the basic concept
最终一致性
RocketMQ eventual consistency is a distributed transaction , that it guarantees the eventual consistency is the message, not as strong as the same distributed transaction 2PC, 3PC, TCC, as to why it is the ultimate consistency affairs in detail below instructions.
Half Message(半消息)
Consumer consumption means temporarily be news . Producer message has been successfully sent to the end of the Broker, but this message is marked as 暂不能投递a state, in the message in this state is referred to a half messages. Need Producer
The message 二次确认after, Consumer order to consume it.
消息回查
Flash due to network segments, the producer restart of the application and other factors. Producer has not lead to the end of Half Message (semi messages) were secondary confirmation . This is Brock server periodically scans 长期处于半消息的消息, will
Ask about the final state (end of the message Producer Commit or the Rollback ), the message is the message back check .
2, distributed transaction interaction process
Ali understood this official chart, we can understand the principle of the distributed transaction RocketMQ.
Let us show that under the above image
1、A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
2、当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
3、执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
4.1)、如果本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就可以消费该message。
4.2)、如果本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
4.3)、如果因为网络等原因迟迟没有返回失败还是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。
It can be learned from the above process 只有A服务本地事务执行成功 ，B服务才能消费该message.
Then let us ponder a few questions?
为什么要先发送Half Message(半消息)
I think there are two main
1）可以先确认 Brock服务器是否正常 ，如果半消息都发送失败了 那说明Brock挂了。
2）可以通过半消息来回查事务，如果半消息发送成功后一直没有被二次确认，那么就会回查事务状态。
什么情况会回查
There are also two cases
1）执行本地事务的时候，由于突然网络等原因一直没有返回执行事务的结果(commit或者rollback)导致最终返回UNKNOW，那么就会回查。
2) 本地事务执行成功后，返回Commit进行消息二次确认的时候的服务挂了，在重启服务那么这个时候在brock端
它还是个Half Message(半消息)，这也会回查。
Special attention : If you check back, so be sure to see the implementation of the current transaction, look at the need to re-run local affairs.
Imagine if the second case occurs due to check back if you do not first check the implementation of the current transaction, but directly execute a transaction, then it is equivalent to the successful implementation of the two local affairs.
为什么说MQ是最终一致性事务
By the picture above, we can see that, in the above example inconsistent affairs both cases, never happen
A账户减100 （失败），B账户加100 （成功）
Because : if A local transaction services have failed, and that B services will never do anything, because the message probably never reached the B services.
Then the A accounts minus 100 (success), B accounts plus 100 (failure) would not be possible.
The answer is yes
A service because when I was only responsible for the successful implementation of the message, the message can ensure delivery to the B, B Service As A final execution result after receiving the message and no matter what.
B service that failure how to do?
If the B final fails, the code is almost certainly why they have a problem caused by abnormal, since the consumer side has RocketMQ retry mechanism, if the code is not usually a problem a few retries can be successful.
If the reason code is caused after several retries fail, it does not matter, the anomalies recorded by the 人工处理after treatment artificial reveal all the details, you can let matters reach a final agreement.
