All articles
https://www.cnblogs.com/lay2017/p/12078232.html
text
Previous article, we first understand the 2pc, know the problem of resources 2pc lead to strong consistency is locked for a long time. Then, we learned about 3pc, 3pc increase the time-out mechanism on the basis of 2pc, in an attempt to solve the problem caused by strong consistency, but the timeout mechanism will obviously result in inconsistent data may be true, but does not really solve 2pc 3pc data consistency problems.
tcc two-phase commit protocol compensating transactions
This article will be submitted with 2pc like to know a transaction agreement, tcc transaction commit protocol, full name is: try-confirm-cancel, the transaction is also divided into a two-phase commit protocol, as shown in Figure
tcc transaction commit protocol is divided into two stages:
1) a stage, the main business try (try) called from the business, not directly from the implementation of the business, but rather a reserve action. For example, the deduction of inventory problems, not directly deduct stock, but reserved a deduction field that indicates how much to deduct inventory.
2) Phase II, in the case of returns yes from the business, the main business will confirm the reservation before the operation (confirm), that is, before the deduction will be based on direct field inventory of deduction. If that is not the case of all yes, it calls cancel (cancel) request, before deduction of field cancellation.
tcc What is the difference with 2pc
We found that, tcc and 2pc In the above procedure is very like, what are the similarities and differences do?
Same point
tcc and 2pc are two stages, a stage does not perform real business, the second stage to confirm or cancel the results of a phase. So, you will feel both in appearance seems to be very similar.
difference
Developers perception
The essential difference tcc and tcc 2pc is facing is the operational level, 2pc-oriented resource level, what does this mean?
When we learn 2pc, we always say is prepare a stage of the transaction, which is not true to commit the transaction. That update the resource does not actually perform, document preparation commit or rollback the second stage in the transaction log. But these developers are not aware of the fact that developers are still on the resources of a single update operation.
而tcc，它的一阶段进行try预留操作，也就是说开发者需要从业务层面来考虑这个问题，提供try-confirm-cancel这样的一个业务逻辑来为维护事务提交，开发者对此是感知得很明显的。我们也可以理解为对业务的入侵。
强一致性和最终一致性
2pc在一定程度上我们称之为强一致性，所以2pc的执行过程会独占资源，持有资源的互斥锁，这也是2pc效率比较低的原因。而tcc虽然增加了业务代码的复杂性，但是在业务层面上避免长时间占用资源，通过一种confirm或cancel的补偿机制来完成整个业务操作，也就是保持最终一致性。最终一致性并不需要长时间持有资源的锁，每一个事务其实都是相互独立的，所以tcc的效率会更高。
总结
我们看到，tcc和2pc非常的相似，都是两阶段的性质。但是，2pc从事务资源的角度利用强一致性来解决问题，显得有些效率低下。而tcc从业务角度来解决问题，把强一致性改成了最终一致性，大大提高了效率。但是tcc明显对代码造成了入侵，你原本只需要一个接口，就不得不拆分成三个接口来处理，对开发者的要求也会更高。
另外，2pc在二阶段如果出现网络故障的情况，即使利用持久化的事务日志补偿处理也会从强一致性变成最终一致性。而tcc从一开始就决定不维护强一致性，而是遵循最终一致性。这样看来，tcc虽然增加了开发的复杂度问题，但是在使用上会更加地高效，稳定，即使极端情况下确实需要人工干预，最终一致性也能够保持。