Concept of TCC (Try-Confirm-Cancel), and was first used by Pat Helland, published in 2007, titled "Life beyond Distributed Transactions: an Apostate's Opinion" papers presented. In this paper, TCC or to Tentative-Confirmation-Cancellation as a name; formally Try-Confirm-Cancel as the name may be Atomikos (Gregor Hohpe written books "Enterprise Integration Patterns" in the introduction to a collection of the TCC, mention to Atomikos of Try-Confirm-Cancel, and believes the two are similar in concept).
TCC transaction mechanism with respect to conventional transaction mechanism (X / Open XA Two-Phase-Commit), characterized in that it does not rely on the resource manager (RM) XA support, but by the business logic (provided by the service system) scheduling to achieve a distributed transaction.
For business systems in a specific business logic S, when its foreign service, must accept some uncertainty, that one call business logic execution is only a temporary operation, calling its consumer service M retained the follow-up cancellation rights. If you think that M global transaction should rollback, it will be asked to cancel the interim before the operation, which will correspond to a cancel operation of S; and when M think global transaction should commit, it will give up the right to cancel the temporary operation before, this corresponds to S is a confirmation operation.
Each initial operation, will eventually be confirmed or canceled. Therefore, to provide for a specific business services, TCC transaction mechanism needs of business systems business logic of three sections: a preliminary operation Try, confirm the operation Confirm, cancel Cancel.
1, the initial operation (Try)
TCC transaction mechanism business logic (the Try), from the execution stage of view, the conventional transaction mechanism with the same business logic. But from a business perspective, it is not the same. TCC mechanisms Try is only a preliminary operation, and its subsequent confirmation together can really constitute a complete business logic. It can be considered:
Traditional business transaction logic = mechanisms preliminary operations (the Try) transaction mechanism TCC TCC + transaction validation logic mechanism (Confirm).
TCC mechanism traditional transaction mechanism business logic into two, namely the part retained after the split preliminary operations (the Try); and the separated part is the confirmation operation (Confirm The), is delayed until the transaction commits stages.
TCC affairs mechanism initial operation (Try) as the center, to confirm the operation (Confirm) and cancel (Cancel) are around the start of preliminary operations (Try). Therefore, the operation Try stages, it is the guarantee of the best, if they fail, there is still cancel (Cancel) which can be adversely affected retracement.
2, confirm the operation (Confirm The)
Confirm the operation (Confirm) is a supplement to the initial operation (Try) a. When TCC Transaction Manager decided to commit global transactions will be executed one by one to confirm the operation (Confirm) preliminary operations (Try) specified the items preliminary operations (Try) unfinished finalized.
3, cancel the operation (Cancel)
Cancel (Cancel) is a retracement of preliminary operations (Try) a. When TCC Transaction Manager decided to rollback a global transaction, the initial operation will be executed one by one (Try) designated to cancel the operation (Cancel), the preliminary operating items (Try) has completed the full withdrawal.
TCC For example:
随着用户量越来越大，对系统的可用性要求越来越高，将一个单体应用拆分为微服务组成的应用的需求应运而生。其实，微服务听起来很美好，但是其中还有很多坑的。In the original monomer applications, orders and inventory retrieval module you want to pay, simply call the relevant class or interface on it, using a database, you can easily put all the operations into a transaction, to ensure that no but the stock will be deducted the payment failure.
But when the system became distributed, the original call between processes into a HTTP calls across the network, this database has become more independent databases from a single database, no effect of the original transaction.
When we build a distributed system, it may not help to make some assumptions that in the long run, will lead to big trouble, such as:
1, the network is reliable
2, do not delay call
3, the network is secure
But the possibility of failure of the network calls is very high, but the situation is not very likely to pay deducted inventory.
How to make deductions inventory and payment services can be completed in a similar transaction database, either do or do not do it?
In fact, this principle is very simple distributed transaction, its essence is to freeze resources and idempotent. Idempotence whether to perform an action a thousand times a thousand times, the effect is the same and performed once. Freeze resources how to understand it?
举个例子吧，订单服务要调用库存服务扣减库存（假设数量为2），还要调用支付服务从用户余额扣钱（假设为100）， 那订单服务第一步就告诉库存服务，给我冻结2个库存； 告诉支付服务，给我冻结100块钱。在这一步，两个服务要做业务检查，看看库存余额够不够，如果足够，就冻结他们，防止其他调用也进行了扣减操作，导致本次调用余额不足。 这一步，我们称之为尝试(Try)。
库存服务和支付服务操作的都是自己的表，冻结操作可以放到一个本地事务中，保证原子性。
这一步如果成功完成，订单服务就可以进入第二步，通知这两个服务真正执行扣减操作，这一步叫做Confirm。
如果调用支付服务进行Confirm时出错了怎么办？？那就告诉库存服务和订单服务都进行Cancel操作，把冻结的数量进行恢复。Above this mechanism is called Try-Confirm-Cancel, referred to as the TCC. For each micro terms of service, we must try, confirm, cancel these three interfaces, in addition to each micro also have a special service to manage TCC components.
- Abnormal Scene
1, inventory services Try the operation is completed, payment services Try the operation is not completed, how do?
Cancel orders can try the service operation to invoke the inventory of (this should be idempotent operation, multiple calls), the release of frozen inventory.
If a network problem, service orders can not be contacted inventory service of it?
TCC component inventory services can be found frozen in time has expired, it will automatically freeze the stock to be released.
2. Try operating two micro-services are completed, then the occurrence of a network failure that can not be two Confirm?
And look at the first case, TCC components will find time out, the release of frozen resources, of course, frozen this part of the resources can not be used over a period of time before release.
However, if the machine where the inventory service has been hang of it? How to calculate overtime?
TCC have to log system, those things did not complete the record, persisted to the hard disk. So next time you can then perform a restart.
3, Try operations are completed, resources have been frozen, in the third step stock success Confirm service, inventory deductions made, but payment service hung up, the balance is still in a frozen state, how do?
You can try several times, so do the Confirm payment service operation (Obviously, this Confirm operations have to be a power and other operations for the job). If it is not successful, it would allow the service to do inventory Cancel the operation. If that does not work, only to let the human intervention.
Apart from the above exceptions, there are still problems to achieve levels:
(1) is to try (to freeze resources), confrim, cancel (resource recovery) such operations require programmers to write code.
For example, for payment services, to achieve at least three methods:
tryPayment(......)
confirmPayment(......)
cancelPayment(......) TCC framework so we can go call.
(2) have their own TCC put forward a framework.
TCC framework does have some ready-made, such as Atomikos, tcc-transaction, Hmily, etc., but those who try, confrim, cancel a business method, programmers have to write captive. You can also try under another eventual consistency model: BASE.
Reference Address:
https://blog.csdn.net/weixin_39800144/article/details/86238305
https://blog.csdn.net/xybelieve1990/article/details/84939770