Distributed theory
ACID characteristics of database transactions
Database transaction characteristics include atomicity (Atomicity), consistency (Conistency), isolation or independence (Isolation) and durability (Durabilily). The following order is taken as an example. In the single e-commerce system, the order service is called, and the entire service operation is completed in the same transaction. After the order is placed successfully, inventory deduction and order generation will take effect at the same time, and the data will be written to the inventory database and order database. The process is as follows:
In a distributed system, if the order service is only micro-serviceized, the order service will be split into calling order service API and commodity service API. After the microservices are split, the order service API corresponds to an independent order database, and the commodity service API corresponds to an independent commodity database. If you just follow the process in the single service and just replace the original local method with the microservice API, the flow chart is as follows:
In ordering service, use RPC or HTTP request to call the goods service API and order service API, similar to the way that the client calls the server. At this time, if the following two problems occur:
- The network is abnormal , the client calls the server service call successfully, but because of the network abnormality, the client shows that the call failed.
- The server is down , the client calls the server service call successfully, but the server is down, the client shows that the call failed.
The flow chart is as follows:
Because, for the above two reasons, the data status of the product and the order data will be inconsistent, as follows:
- The order service rolls back because the network is abnormal or the server is down. The order data rollback does not generate data in the order database, and the goods service call is successful, and the inventory deduction in the goods database is successful.
- The order service call was successful, the generated order data was written to the order database, and the merchandise service failed to be called due to network abnormalities or server downtime, and the inventory in the merchandise database did not change.
Two-stage submission of CAP theory and database (2PC)
How to solve the problem of inconsistent data status after directly split into microservices? At this time, it is necessary to introduce distributed transactions. First of all, I will think of implementing distributed transactions through the two-phase commit (2PC) of the database, which belongs to the database-level implementation plan. According to CAP theory (for details, please refer to in-depth understanding of CAP theory and applicable scenarios ), 2PC belongs to CP mode .
Students who understand the distributed affairs of the database must know that the 2PC supported by the database is also called XA Transactions. Among them, XA is a two-phase submission agreement, the agreement is divided into the following two stages:
- The first stage: the transaction coordinator requires each database involved in the transaction to precommit (precommit) this operation and reflect whether it can be committed.
- The second stage: the transaction coordinator requires each database to submit data.
Among them, if any database vetoes this submission, then all database operation data will be rolled back. This method will have serious performance impact, and also has the following disadvantages:
- Synchronous blocking problem! During execution, all participating nodes are transaction blocking. When participants occupy public resources, access to public resources by other third-party nodes is also blocked.
- Single point of failure! Due to the importance of the coordinator, once the coordinator fails, the participants will continue to block. Especially in the second stage, when the coordinator fails, all participants are still in the state of locking transaction resources, and cannot continue to complete transaction operations.
- The data is inconsistent! In the two-phase submission process, when the coordinator sent a commit request to the participants, a network abnormality or server downtime occurred , which would result in partial data submission success and partial submission failure, resulting in data inconsistency.
TCC mode transaction
Due to the 2PC mode, the availability is not high, and the performance is very poor, and it also belongs to a long transaction process. The beginning of TCC mode is a bit similar to 2PC. TCC is essentially a way of compensation. It divides the transaction process into two stages of Try, Confirm / Cancel, and the three steps of Try, Confirm and Cancel are as follows:
- The Try phase is mainly for the detection and resource reservation of the business system.
- The Confirm phase is mainly to confirm and submit the business system. After the Try phase is successfully executed, the Confirm phase is executed.
-
The Cancel phase is mainly for business execution errors. After the Try phase fails, it is used to cancel the business executed in the Try phase and release the reserved resources.
In addition, the TCC mode, compared with the 2PC mode, has a smaller granularity of transaction control. In the three steps of Try, Confirm, and Cancel, when services call each other, transactions between services are individually controlled. Take tcc-transaction (specific code example can refer to tcc-transaction-use guide 1.2.x ) as an example to introduce TCC mode specifically.
tcc-transaction execution flow
In tcc-transaction, the concept of Transaction transaction is defined at the business level . When the two stages of Try and Confirm / Cancel are executed, different service APIs control their own transactions. And, based on the database transaction REQUIRED propagation attribute (that is, if an active transaction exists, it runs in a nested transaction. If there is no active transaction, it is executed according to the NESTED attribute. It uses a separate transaction, this transaction has Multiple savepoints that can be rolled back), the same transaction is used when the two phases are executed. The execution flow chart is as follows:
tcc-transaction idempotent processing
During the execution of logic in Try and Confirm / Cancel, some built-in business exceptions may be thrown, such as timeout exception SocketTimeoutException, optimistic lock exception OptimisticLockException, and some other custom business exceptions. At this time, as long as these two phases are retried several times, it may be successful. Therefore, the business code in these two stages must satisfy idempotent processing.
