Distributed Transaction 2

Commonplace - distributed transactions using the message queue

This talk about the problem of distributed transactions. Enterprise architecture by now turned to the traditional architecture of the micro-service architecture, as shown below:

So, are inevitably encountered the problem of distributed transactions across database calls!
Currently, the industry solve the problem of distributed transactions, they are the basic need JTA strong consistency of this solution is basically using the following two options

  • Transaction-based framework of TCC
  • message queue

OK, you first remember two things
(1) A service and service B in the figure, if it is a synchronous call, together with the required success, or failure together, then the time should be used in the framework of TCC's affairs, which I write another one another day articles, first digging!
(2) A in FIG service and service B, if it is an asynchronous call, such as call services A to C the service, the service execution result of the service do not control C B directly returned, then in this case, should be used in the message queue! This article focuses on talking about!
So far, most of the articles are talking about too complicated. After reading so many new leads before reading this article, you forget the first concept you see in other articles, to go along with the idea of bloggers!

text

Give everyone a set of business scenarios, it is also a very common asynchronous invocation scenario:

  • Alipay transfer money to the balance of treasure

A serving is about to assume Alipay, service B is assumed to be the balance of treasure.
So, let's turn to pay Bao Bao 100 dollars to balance is how to do it?
Particularly easy, by means of message queues can, as shown in FIG.

Consistency solve

OK, this top version has a fatal problem! As follows

Transaction Start
(1) to a PayPal account zhangsan, buckle 100 yuan
(2) (to balance zhangsan PayPal account, plus 100) is encapsulated message, sent to the message queue
end of the transaction

I dare you, how to ensure that the first step and the second step is done in the same transaction. In other words, the first operation of the database, the second step is a message queue, how do you ensure consistency between these two steps?
Remember, any business related to the logical operation between the database and middleware, we need to consider consistency between the two. For example, you first operate the database, and then operate between how caching, database and cache consistency to solve? Well, if a blogger iron powder, should know how to solve, back to our scenario.
Change ideas, plus a transaction table, as shown in FIG.

 

Note that, at this time the contents of the transaction is

Transaction start
(1) to the PayPal account zhangsan, buckle 100 yuan
(2) to the event table to insert a record
transaction ends

At this point is two tables in the same database operation, and therefore can guarantee a transaction database.
Further, the timing of starting a program, the timing of scanning the transaction table, a state is found 'UNFINISHED' events, it encapsulates the message, the message is sent to the middleware, and then change the status to 'FINISHED'.

 

Idempotence solve

Note that the this version there is a problem idempotency!
Look carefully timed program does the following three operations
(1) the timing of scanning the transaction table, a state is found 'UNFINISHED' events
(2) the event information, the package message is sent to the messaging middleware
(3) to the event state 'FINISHED'

The OK, assumed in step (2), when, after sending the message body, has not been performed in step (3), the timer program killed! Then restart the timer program, found just the status of the transaction is still 'UNFINISHED', thus resent. In this way, there will be double-spending problem. Therefore, idempotency also need assurance!

如果是博主的忠实读者,应该知道,博主曾经写过一篇《分布式之消息队列复习精讲》,里头就提到了如何解决幂等性问题。什么?你没看过这篇?拉出去枪毙!
借用这篇文章里的方案。在消费者端,也维护一个带主键的表,可以选txid为主键,如下图所示

如果一旦出现重复消费,则在事务里直接报出主键冲突错误,从而保证了幂等性!

面试连环炮

面试官:"你们用了微服务架构么?"
求职者:"用了,用了"
面试官:"怎么解决分布式事务的啊?"
求职者:"我们的服务刚好是异步的场景,所以用消息队列!"
面试官:"怎么保证一致性和幂等性啊?"
求职者:"嗯,听我细细说来....."

总结

这篇文章说了微服务架构下,异步服务之间的分布式事务是如何保证的。

Guess you like

Origin www.cnblogs.com/longxok/p/10932398.html