Transactions and distributed transactions
Standalone transaction we often see, distributed transaction, popular point will be, is the need to run on each machine transaction, but each step of the transaction does not know whether the other step is successful, but in the business and to ensure that all steps, either successful, or not.
How distributed transactions are implemented (Dry goods)
- Distributed transactions based on message implementation
- Distributed Transactions Based on Compensation Implementation (form of GTS/FESCAR automatic compensation)
- Distributed transactions based on TCC implementation
- Distributed transactions based on the SAGA implementation
- Distributed transaction based on 2PC implementation
When to use single-machine transactions
The believe that it is clear to all, in situations where conditions permit, we should as far as possible using a single transaction, because single transaction, no additional coordinate with other data sources, to reduce the network interaction time consumption and the coordination and the storage time, IO consumption under the changing the amount of business data, single transactions will have higher performance.
When to choose message-based transactions?
Message-based transactions are suitable for business scenarios where the commit or rollback of a distributed transaction depends only on the business needs of the transaction initiator and data changes of other data sources follow the initiator.
As an example, consider a business rule: when an order is successful, a certain amount of credit is added to the user.
In this rule, the service that manages the order data source is the transaction initiator and the service that manages the integral data source is the transaction follower.
As you can see from this procedure, a message queue-based transaction has the following operations:
Order service Creates an order, submits a local transaction order service publishes a message integral service adds points after receiving the message We can see that its overall process is relatively simple, while the workload of business development is not large:
Written order service in order to create the logic of writing scores increase in service logic Process is simple, you can see the transaction form performance overhead is small, the initiator and follow the traffic between the peak valley fill and level up, can use the queue and business development effort with single transaction no difference, do not need to write the business logic of the reverse process. Therefore, message queue-based transactions are our top priority in addition to single machine transactions.
But how to ensure the reliability of the message, it is up to us to deal with. Take a look at this article: Spring Cloud implements Reliable message consistency. This brother has written in great detail, so I won’t go into details
When to choose a transaction implemented with compensation?
But message-based transactions do not solve all business scenarios, such as when an order is completed and the user’s cash is deducted.
In this case, the transaction initiator is the service that manages the order base, but whether the entire transaction is committed or not is not determined by the order service alone, because the user also needs to make sure that they have enough money to complete the transaction, and this information is in the service that manages the cash. Here we can introduce a transaction based on compensation implementation, and its flow is as follows:
Create order data, but not submitted local transaction order service to send a remote call to cash, to deduct the corresponding amount of the above steps successfully submit orders after the transaction Is more than the normal process of success, abnormal process needs to roll back, will send a remote call to the extra cash services to add the amount deducted before.
The above processes are more complex and require more work to develop than those based on message queues:
Written order created in the service order logic to write cash service buckles money logic written in service logic of compensation in return As you can see, the transaction process relative to the implementation of a distributed transaction message to more complicated and requires additional rollback method development related business, has lost its peak flow between service cut function. However, it is only a little more complex than message-based transactions, and if message-queue-based final consistency transactions are not possible, a compensation-based transaction form can be preferred.
Ali GTS/ FESCAR is essentially a programming model for this compensation, except that the compensation code is automatically generated without business intervention and takes over the application data source, forbidding business to modify records in the global transaction state. Therefore, its applicability to read scenarios can be referred to compensation. However, its write applicability is between TCC and compensation because of the global transaction write lock.
When to choose transactions implemented using TCC
However, the compensation-based transaction pattern does not fulfill all requirements, such as the following scenario: when an order is completed, the user’s cash is deducted, but the transaction is not completed or cancelled, the customer cannot see the money is less.
At this point, we can introduce TCC, and its process is as follows:
Order service creation order order service to send a remote call to cash, the cash of the freeze customers submit orders service orders data service to send a remote call to cash, deducted from the customer above freezing cash is a normal process to do it, if abnormal process, you will need to send a remote service invocation request to cash, cancel the freeze of amount.
The above process is more complex than the process based on compensation-based transactions and requires more work to develop:
Order service to write to create order logic cash service write freeze logic cash service write to deduct logic cash service write thaw logic TCC is actually the most complex kind of situation, it can deal with all the business scenario, but no matter for performance reasons, or development complexity considerations, Such transactions should be avoided as much as possible. So we developed a TCC framework for most business scenarios, which we’ll write about in the next article
When do you choose to leverage transactions implemented by SAGA?
SAGA can be thought of as an asynchronous, queue-implemented compensation transaction.
It is applicable to scenarios where it is not necessary to return the final status of the service initiator immediately, for example: your request has been submitted, please check later or pay attention to the notification.
Rewrite the above compensation transaction scenario with SAGA, and its process is as follows:
Order service create a final state of the unknown order record, and submit the cash transaction services to deduct the required amount, and to commit the transaction order service update order status to success, and to commit the transaction above for successful process, if cash service deduct amount of failure, so, the last step order service will update order status for failure.
Its business coding is a bit more work than compensation transactions and includes the following:
Order service create the initial order logic order confirmation order successful logical order service orders failed deducts cash the logic of the service logic cash compensation to return cash logic But its relative to the compensating transactions form has the advantage of performance, all the local child during the execution of a transaction, all transaction execution, without waiting for the call The locking time is reduced, which is more advantageous in long transactions. At the same time, it uses queue to communicate, which has the function of cutting peak and filling valley.
Therefore, this form is suitable for business scenarios that do not need to synchronously return the initiator to execute the final result, can be compensated, have high performance requirements, and do not mind additional coding.
But of course SAGA could be tweaked into a form similar to TCC that allows for resource reservation.
2 PC transaction
It is suitable for scenarios where there are few participants, the execution time of a single local transaction is small, and the availability of the participants themselves is high, which is otherwise likely to result in severe performance degradation.
By analyzing, we can find that there is no one transaction mode that can solve all problems. We need to choose the appropriate transaction mode according to the specific business scenario. Sometimes it is even necessary to mix multiple transaction patterns to better achieve the goal, such as the order/points/wallet hybrid scenario mentioned above: The success of the order depends on the balance of the wallet, but not on the number of credits, so you can mix message-based transaction patterns to add credits and compensation-based transaction patterns to ensure a successful deduction, resulting in a better performance and less coding pattern.
However, at present, many frameworks are focused on a single aspect of the transaction form, such as TCC framework, reliable message framework, SAGA framework, they are independent, easy to lead to the following problems:
Due to early adopt only one type of transaction framework, because the tools now only a hammer, the introduction of other tools and involves testing, read the code, such as process, so the all problem as a nail, lead to low performance or to achieve enough grace Due to different transaction form may not be consistent framework management, result in not good coordination, For example, one TCC framework and another message-based transaction framework do not mix well.
conclusion
Different business scenarios should introduce different transaction patterns as required.