Talk about distributed transactions

As long as the distributed system involved, in any case will encounter distributed transactions, of course, you can reasonably split the system, planning tables and library structure, but this is only to reduce the number of distributed transactions, for example, you have 5 places in the original system has distributed transactions, now an optimization may only have 3 places, But you're not going to have any, personally, it's unlikely.

Next talk about what happens when a distributed transaction is generated?

One: Same database, different Web containers

As we know, our order system and inventory system are connected to the same data source, and there is only one database in the data source, which contains the order form and inventory table. Because the order system and inventory system are two different systems, deployed on two servers, they are called through the interface, so although they are two tables in the same database, but we can not do transaction manipulation. In terms of business, when we place the order, the inventory of goods must be deducted, can not stock buckle, the order did not generate, or the order generated, inventory does not buckle, so not chaos it? So the two-step operation of the inventory and order generation must either be done or not, which involves distributed transactions.

Two: Different data sources, same web container

This time we wrote the operation and the button inventory in the same system and deployed on a server, the system is connected to two data sources, namely the Order database and inventory database. Obviously, although we have business logic written in a system, but you are connected to two data sources, so there is a distributed transaction.

Three different databases, different web containers

The third case is somewhat similar to the combination of the first and the second. Each system manipulates its own database, and the system is called through an interface, and it is clear that there must be a distributed transaction

Four single-table sharding cases

Sometimes the number of a table is too big, and the growth rate is too strong, then helpless, can only be divided into several pieces of this table into a different database server above, some people will say why this will also generate distributed transactions? According to the above diagram I give an example, if the inventory table Shard 1 storage is the warehouse of Shanghai Commodity inventory information, inventory table Shard 2 storage is Beijing warehouse inventory information, now I want to transfer operations, from the Shanghai warehouse transfer 500 iphone mobile phone to Beijing warehouse, This time we will be 1 deduction 500 of the operation, and the Shard 2 to increase the operation of 500, then we can allow this operation to fail? My Shard 1 (Shanghai warehouse) 500 units deducted, but Shard 2 (Beijing Warehouse) did not increase success? This obviously is not possible, so this involves a distributed transaction, of course, I just give an example, because you are involved in the same table more than two records to modify the operation, so the distributed transaction.

Above we talk about what kind of situation will appear distributed transaction, next the solution

One: JTA (two phase commit)

In fact, JTA strictly can not solve the distributed transaction, for example, I above the first case, I am a single data source, different Web containers, you use JTA how to solve? JTA only resolves transactions under multiple data sources, and has a significant impact on the throughput of the system.

Second: Compensation method

This is the most commonly used method at the moment.

First we need to divide our business into the finest, so that each business becomes an atomic business, let's say we have a business that can now be divided into 3 atomic businesses, business A, business B, business C. These business operations can be either you manipulate the database directly, or you can call an interface to another system

Suppose we now have business a business B all executed successfully, but business C has failed here. Then we have two paths to go.

Article One: rollback of Business A and business B, i.e. revocation of business A and business B.

Article two: Continue to execute business C until successful

In both directions we are also called forward and reverse, in fact the second is commonly used, if you push the words of the front to undo all, I do not feel very meaningful, when you generate compensation behavior, our mainstream process actually has gone through, for example, you place a single operation, the user orders after the order, You tell it that you have successfully put orders, OK Next and the user does not matter, this is called the main process is over. But your order process contains the deployment of inventory, such as my orders in Shanghai, to Beijing warehouse to transfer goods, then involved in the distribution of transactions (can refer to the fourth case of distributed transactions), well now the Beijing Treasury call failed, then I began to reverse the order to delete, you think it is appropriate? Or I continue to push forward, until I call success, the user over there I just display in the order on the delivery is ready, anyway you have to delete the order, it would be a very bad experience

Talk about distributed transactions