テキスト
図に示すように、我々はまず、ビジネスシナリオに設定してください。
決済サービスを呼び出し、その後、我々は戻って、次の3つのステップを達成したいポイント、ページ支払いボタン
[1]注文サービス-注文状況を修正する
[2]アカウントサービス-お金を控除
[3]インベントリサービス-在庫控除
達した業務を効果、一緒に成功するか失敗一緒にどちらか！TCCは、分散トランザクション・プログラムを取ることが必要です！
コンセプト
TCCは、（トライ確認し-キャンセル）立っています。図に示すように。
PS：TCCと二相補償問題呼び出すことができる、唯一の第一段階は、リソースを予約しようとすると、明確に/キャンセル確認の第二段階に対応し、あなたが最後にやりたいリソースをサービスプロバイダに指示する第二段階、と第一段階の効果、いわゆる補償事項を削除します。
もう一つのアナロジーは、TCCは、それが大きすぎると言う、のRMは、準備コミット、インターフェースをロールバック、常にそれを知っていると言います。アナロジーはとても理解することができ
それは？その違い
ROLLBACKは、開発者のレベルを立って、PREPAREコミットは感知できない、データベースのリソースは、あなたが操作を行う助けて！するために
感じることができ、開発者のレベルをされて立って、キャンセル、確認して、してみてください、これらの3つの方法のビジネスロジックは、すなわちリソースの操作、開発者が達成するために自分自身にあります！
さて、ここで我々はそれを行う方法を、シーンを設定します。たとえば、サービスは1つのインタフェースだけを持っていた注文します
//修改代码状态
orderClient.updateStatus()；これはつまり、3つのインターフェースに分割され
orderClient.tryUpateStatus()；
orderClient.confirmUpateStatus()；
orderClient.cancelUpateStatus()；注意：インタビュアーがあなたを尋ねられた場合は、TCC欠点は何ですか？これは非常に重大な欠点がある大規模なコード***！各サービスロジックは、トライプレス（リソース要求）は、3つのインターフェースに分け、（キャンセルリソース）をキャンセルし、（操作のリソースを）確認しなければなりません！
具体每个阶段，每个服务业务逻辑是什么样的呢?
假设，库存数量本来是50，那么可销售库存也是50。账户余额为50,可用余额也为50。用户下单，买了1个单价为1元的商品。流程如下:
Try阶段
订单服务:修改订单的状态为支付中
账户服务:账户余额不变，可用余额减1，然后将1这个数字冻结在一个单独的字段里
库存服务:库存数量不变，可销售库存减1，然后将1这个数字冻结在一个单独的字段里
confirm阶段
订单服务:修改订单的状态为支付完成
账户服务:账户余额变为(当前值减冻结字段的值)，可用余额不变(Try阶段减过了),冻结字段清0。
库存服务:库存变为(当前值减冻结字段的值)，可销售库存不变(Try阶段减过了)，冻结字段清0。
cancel阶段
订单服务:修改订单的状态为未支付
账户服务:账户余额不变，可用余额变为(当前值加冻结字段的值)，冻结字段清0。
库存服务:库存不变，可销售库存变为(当前值加冻结字段的值)，冻结字段清0。
伪代码
接下来从代码程序来说明，为了便于演示，将入参略去。
本来，你支付服务的代码是长下面这样的
那么，用上TCC模型后，代码变成下面这样
注意了，这种写法其实严格上来说，不是不行。看你业务场景，因为存在一些瑕疵，看你自己有没办法接受
(1)cancel或者confirm出现异常了，你怎么处理？
例如在cancel阶段执行如下三行代码
orderClient.cancelUpdateStatus();
accountClient.cancelDecrease();
repositoryClient.cancelDecrease();あなたの2行目は異常で、3行目には、どのように行うために終了し実行されませんでしたか？これを補うために、あなたはビジネスを行います！
（2）重複したロジックを多数
見て、ああ、私たちの実行アーキテクチャの事実は、これがあります
try{
xxclient.try();
}catch(Throwable t){
xxclient.cancel();
throw t;
}
xxclient.confirm();実行するためのフレームワークには、この棚を作るための方法はありません、我々はあなたが各段階でのように実行する方法の枠組みを、教えて！
したがって、TCC分散トランザクションフレームワークを導入してみ、確認して、知覚するフレームワークへの事務の3つの状態を解除する必要があります！あなただけの！何を実行するために何を、キャンセルを行うには確認して何を、実行しようと、フレームワークを伝える例外が発生した場合の処理をキャンセルし、フレームはあなたのデータを復元するための内部救済を持っています！
例外がキャンセルしたり、異常事態が発生した場合に確認TCC分散フレームワークhmilyたとえば、ステージはログを維持しようと、Hmilyが内蔵されているスケジューラ・スレッド・プール回復し、心配しないでください。
それhmily、状態がそれをどのように感じますか？それはプログラミングのセクション、次の行のコアロジックで、また非常に簡単です
私たちは、限り、注釈は、フレームワークの確認を指示するよう、キャンセル@Tccによる実行のどのような方法方法があることができるもの行い、使用します！あなたがに対処するためのフレームに他の！
まあ、言っても過言ではない、何もhmilyソースが解決されたと言う、我々は自分自身を知るための時間を持っています！
開削
あなたは、異なるプラットフォーム間で呼び出すことをヒットした場合、どのように取引することを確実にするでしょうか？たとえば、インターフェイスに私の銀行振込サービスは、あなたは、銀行がそれをあなたのTCCフレームを取ることができる可能性があると思いますか？あるいは、銀行があなたのニュースの列を見てみましょうか？あなたはそれが現実的だと思いますか？もちろん、一部の人は言うだろう：「1つのHTTPダイレクトチューン。」ああ、ティーンエイジャーは、アイデアを持っています！
[OK]を、ので、サードパーティのインターフェイスに関連するようなサービスコールの業界、そしてどのように一貫性を確保するには？私たちは熟考します。