すべての記事
https://www.cnblogs.com/lay2017/p/12078232.html
テキスト
前の記事で、我々は最初の強い一貫性へのリソース2PCリードの問題を知っている、2PCを理解し、長い時間のためにロックされています。その後、我々は強い整合性による問題を解決するために、2PCに基づいてタイムアウトメカニズムを高める3PC、3PCについて学んだが、明らかに矛盾したデータになりますタイムアウトメカニズムは本当かもしれないが、実際には、2PC 3PC解決しませんデータ整合性の問題。
TCC 2フェーズプロトコル補償トランザクションをコミット
この記事フルネームがあるTCCトランザクションがコミットプロトコルを、取引契約を知っているように、2PCで提出される、：図に示すように、のtry-確認・キャンセル、トランザクションはまた、二相に分かれているが、コミットプロトコル
TCCトランザクションコミットプロトコルは2つの段階に分かれています。
1）のステージ、ビジネスから呼び出された主な事業トライ（TRY）、直接ではなく、ビジネスの実装ではなく、予備のアクションから。たとえば、在庫の問題ではなく、直接控除株式の控除が、在庫を控除するどのくらいを示し控除フィールドを禁じます。
2）フェーズIIは、ビジネスからのリターンのYESの場合には、主な事業は、控除は、控除の直接フィールドの在庫に基づいてされる前に、あること、操作（確認）する前に予約を確認します。それがすべてYESの場合ではない場合、それはフィールドキャンセルの控除前、（キャンセル）キャンセル要求を呼び出します。
TCC 2PCとの違いは何ですか
私たちは、類似点と相違点は何かあり、上記の手順でTCCと2PCは非常に似ている、ことがわかりましたか？
同じポイント
TCCと2PCは2段階あり、ステージが確認するために、第二段階を実際のビジネスを実行したり、フェーズの結果をキャンセルしません。だから、あなたは外観の両方を感じることが非常に似ているように思えます。
異なる点
開発者の知覚
本質的な違いのTCCおよびTCCの2PCが直面している、これはどういう意味、運用レベル、2PC指向のリソースレベルですか？
我々は2PCを学ぶとき、私たちは常にトランザクションをコミットする場合はtrueではない取引の舞台を準備していると言います。その更新は、リソースが実際に文書作成は、トランザクション・ログ内の第二段階をコミットまたはロールバック、実行されません。しかし、これらの開発者は、開発者は、単一の更新操作のリソースに残っているという事実を認識していません。
而tcc，它的一阶段进行try预留操作，也就是说开发者需要从业务层面来考虑这个问题，提供try-confirm-cancel这样的一个业务逻辑来为维护事务提交，开发者对此是感知得很明显的。我们也可以理解为对业务的入侵。
强一致性和最终一致性
2pc在一定程度上我们称之为强一致性，所以2pc的执行过程会独占资源，持有资源的互斥锁，这也是2pc效率比较低的原因。而tcc虽然增加了业务代码的复杂性，但是在业务层面上避免长时间占用资源，通过一种confirm或cancel的补偿机制来完成整个业务操作，也就是保持最终一致性。最终一致性并不需要长时间持有资源的锁，每一个事务其实都是相互独立的，所以tcc的效率会更高。
总结
我们看到，tcc和2pc非常的相似，都是两阶段的性质。但是，2pc从事务资源的角度利用强一致性来解决问题，显得有些效率低下。而tcc从业务角度来解决问题，把强一致性改成了最终一致性，大大提高了效率。但是tcc明显对代码造成了入侵，你原本只需要一个接口，就不得不拆分成三个接口来处理，对开发者的要求也会更高。
另外，2pc在二阶段如果出现网络故障的情况，即使利用持久化的事务日志补偿处理也会从强一致性变成最终一致性。而tcc从一开始就决定不维护强一致性，而是遵循最终一致性。这样看来，tcc虽然增加了开发的复杂度问题，但是在使用上会更加地高效，稳定，即使极端情况下确实需要人工干预，最终一致性也能够保持。