编程知识 cdmana.com

A detailed explanation of rocketmq distributed transaction principle, do not know how to calculate my input

of RocketMQ Theoretical knowledge of implementing distributed transactions , The next article will also illustrate adopt SpringCloud Let's give an example RocketMQ Projects that implement distributed transactions .

One 、 Take a distributed transaction scenario

The Works of Liezi : hypothesis  A  to  B  turn  100 Yuan , And they're not on the same service .

The goal is : Namely  A  reduce 100 Yuan ,B  Add 100 Yuan .

There may be four practical situations :

1) Namely A Account minus 100 ( success ),B Account plus 100 ( success )

2) Namely A Account minus 100( Failure ),B Account plus 100 ( Failure )

3) Namely A Account minus 100( success ),B Account plus 100 ( Failure )

4) Namely A Account minus 100 ( Failure ),B Account plus 100 ( success )

here   The first 1 And the 2  This situation can guarantee the consistency of transactions , however   The first 3 And the 4  There is no guarantee of transaction consistency .

Let's take a look at RocketMQ How to ensure the consistency of transactions .

Two 、RocketMQ Realize the principle of distributed transaction

RocketMQ Although distributed transactions are supported before , But there's no open source , wait until RocketMQ 4.3 Open source .

1、 Basic concepts

Final consistency

RocketMQ It's a ultimately consistent distributed transaction , That is to say, it guarantees the final consistency of the message , Not like it 2PC、3PC、TCC So strong consistent distributed transactions , As for why it is the final consistency transaction, it will be explained in detail below .

Half Message( Half the news )

Can 't be used temporarily Consumer Message of consumption .Producer The message has been successfully sent to Broker End , But this message is marked as undeliverable , A message in this state is called a half message . need Producer

After a second confirmation of the message ,Consumer To consume it .

Check back

Because of the network flash , Producer application restart and so on . Lead to Producer The end has not been right  Half Message( Half the news )  Conduct   Secondary confirmation . This is a Brock The server will regularly scan messages that are half message for a long time , Meeting

Take the initiative to ask Producer End The final status of the message (Commit perhaps Rollback), The message is   Check back .

2、 Distributed things Interaction process

Understand this official picture of Ali , Can understand RocketMQ The principle of distributed transaction .

 

 

Let's explain the picture above

1、A The service first sends a Half Message to Brock End , Carry in the message B service Coming soon +100 Yuan's information .

2、 When A The service knows Half Message After sending successfully , So start with 3 Step local transaction .

3、 Performing local transactions ( There will be three situations 1、 Successful implementation .2、 Execution failure .3、 No response due to network and other reasons )

4.1)、 If the local transaction succeeds , that Product image Brock Server send Commit, such B Service can be consumed message.

4.2)、 If the local transaction fails , that Product image Brock Server send Rollback, Then the above half message will be deleted .

4.3)、 If you don't return to failure or success because of network and other reasons , Then it will execute RocketMQ Callback interface , To check back the affairs .

From the above process, we can know Only A Service local transaction executed successfully ,B Service is the only way to consume message.

Then let's think about a few more questions ?

Why send first Half Message( Half the news )

I think there are two main points

1) You can confirm Brock Is the server OK , If half of the messages fail to be sent That means Brock Hang up .

2) Transaction can be queried back and forth through half message , If the half message is sent successfully and has not been confirmed twice , Then it will check back the transaction status .

What will be checked back

There are also two situations

1) When executing a local transaction , The result of executing the transaction has not been returned due to sudden network and other reasons (commit perhaps rollback) Leading to the final return of UNKNOW, Then we'll check back .

2) After the local transaction is executed successfully , return Commit The service hung up during the second message confirmation , At the time of service restart, it is brock End

It's still a Half Message( Half the news ), This will also check back .

Particular attention : If you check back , that Be sure to check the execution of the current transaction first , See if you need to re execute the local transaction .

Imagine if there's a second situation that causes a check back , If you don't check the execution of the current transaction first , It's about doing things directly , This is equivalent to two local transactions successfully executed .

Why do you say MQ It's the ultimate consistency transaction

Through the picture above , We can see that , In the above two cases where the transactions are inconsistent , It will never happen

A Account minus 100 ( Failure ),B Account plus 100 ( success )

because : If A Service local transactions failed , that B The service will never do anything , Because the news never reaches B service .

that  A Account minus 100 ( success ),B Account plus 100 ( Failure )  Will it be possible for .

The answer is yes

because A The service is only responsible when my message is executed successfully , Make sure the message reaches B, as for B The final execution result of the service after receiving the message A It doesn't matter .

that B What to do if the service fails ?

If B The final execution failed , It's almost certain that there's something wrong with the code that causes the exception , Because the consumer side RocketMQ There's a retry mechanism , If it's not a code problem, you can usually try again several times to succeed .

If it's the code that causes multiple retries to fail , It doesn't matter , Record the exception , By hand , After the treatment of artificial bottom , You can achieve the ultimate consistency of transactions .

版权声明
本文为[Advanced ape]所创,转载请带上原文链接,感谢
https://cdmana.com/2020/12/20201224222552522d.html

Scroll to Top