トランザクションを分散しているものを1詳細分散トランザクション---
3詳細--- Seata分散トランザクションは、トランザクションのフレームワーク分散します
分散トランザクションの解決策について説明し、ここでは、CAP理論を導入する必要があります。
1 CAP理論
分散トランザクション制御を実行する方法は？
CAPの
理論は、分散トランザクション処理のための基礎であることを理解
CAPの
理論は、私たちは分散トランザクションを研究プログラムに対処するのに役立ちます。
CAPの
理論がある：分散システム設計することができる唯一の一貫性
（一貫性）
、可用性
（アベイラビリティ）
、分割耐性
を満たす2種類のアカウントに3を取ることができないこと（分割耐性）。
図によって理解
CAP
理論値：
一貫性（整合性）
：サービス
A
、
B
、
C
の3つのノードがユーザデータに格納されている、3つのノードは、データの一貫性と同じ時間を維持する必要があります。
アベイラビリティ（可用性）
：サービス
A
、
B
、
C
の3つのノード、一つのノードがダウンし、もしサービスのみサービスを提供するために、クラスタ全体に影響を与えることはありません
Aの
サービスA際に、ノードを
システム全体がサービスのダウンタイムを提供することはありません、増加サービス
B
、
Cは、
システムの可用性を確保します。
分割耐性（分割耐性）
：分割耐性は不完全であるため、データパーティション原因ネットワークの問題のアクセスできない分割耐性を解決するために一緒に動作するようにネットワーク経由でシステムを可能にすることです。
分散システムのシーンの必然的な出現、ネットワークを介して連携して動作する複数のシステムは、必然的に一度原因データに登場したネットワーク遅延の遅延現象は、異なるノード上に広がるように、ネットワークノード間が中断されますこれは、ネットワークパーティションです。
分散システムは、考慮に入れることができますC 、A 、Pを？
あなたは、各ノードのための一貫したデータを達成するために必要なデータの整合性を確保したい場合は前提の下で、整合性パーティショントレランスと可用性を確保するために、あなたはシステムのユーザビリティを向上させたい場合は、ノードの数を増やす必要がある、考慮にノードを取りませんより良く、より可用性のが、データの一貫性に悪化。
そのため、分散システムの設計時に、満足しながら
「
一貫性
」
、
「
可用性
」
と
「
分割耐性
」
3はほとんど不可能です。
CAP
の組み合わせは何ですか？
1 、CA
：に従い、分割耐性、一貫性と可用性リレーショナルデータベースあきらめ
CAの
デザインを。
2 、APは
：可用性と分割耐性、結果整合性の追求、多くの強化、一貫性をあきらめる
のNoSQL
に応じてデータベースを
APの
デザイン。
説明：ここで強い整合性と強い整合性をあきらめて一貫性の手段を放棄が正常に最新のデータをチェックアウトするためにすぐに書かれています。エンドユーザーの受け入れ時に長くすることができますようにと、同じデータを一時的にデータの矛盾を可能にする結果整合手段の追求。
3 、CP
：使いやすさ、一貫性とパーティション寛容をあきらめ、システムはによって強い整合性の数必要と
CPの
ように銀行間の転送、トランザクション全体が完了した銀行システムの両方の完了を待つ転送要求として設計し、。
注：ネットワークの問題により
CPの
仕上げシステムとは取引がブロックされませんがある場合、システムは、タイムアウト、タイムアウトの問題を待っているように見えることがあります。
要約：
分散システムの設計では
APは
より頻繁に、すなわち、可用性とパーティション耐性を確保、データの強い一貫性を犠牲にする、（すぐに最新のデータへの書き込みの後に読み出し）、最終的なデータの整合性を確保します。たとえば：順序口座に入金、返金、返金成功、今日、明日、還付取引は長く、ユーザが所定の許容時間内であるとしてとして完成します。
2つのソリューション
2.1二相コミットプロトコル（2PC）
二相の出現は、プロトコル（分散システムのデータの整合性の問題は解決するためにコミット
2相コミットプロトコル
）、二相がコーディネータと参加者二つの段階で構成され、3つの操作の合計によってコミット、Oracleなどのリレーショナルデータベースの一部を
、
MySQLの
2フェーズ・コミット・プロトコルをサポートし、このセクションでは、リレーショナルデータベース2フェーズ・コミット・プロトコルを説明しています。
参考：
2PC
：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
2PC
プロトコルのフローチャート。
図1に示すように、第一段階：準備フェーズ（PREPARE ）
注文を送信する準備ができて、参加者に通知するコーディネーターは、参加者が投票を始めました。
コーディネーターは、コーディネーターに対応するための準備作業を完了するために
はい
。
2、第二段階：提出（コミット）/ ロールバック（ROLLBACK）ステージ
コーディネーターは、最終的に開始し、投票参加者の結果に応じた指示をコミットします。
何の参加者が存在しない場合は、ロールバックコマンドを開始する準備ができています。
株式の削減の一つの例：
1
、2つのデータソースを接続するアプリケーション。
2は
、2つのライブラリーにトランザクションコーディネータによって起動されたアプリケーションは、
PREPARE
、それはそれはそう答えるだろう成功した場合、2件のメッセージがローカルトランザクション（ログ）を実行するためのデータベースを受けたが、コミットしていない、
そうでない場合は返信、
NOを
。
図3は、
長い一方の当事者が返信するようとして、トランザクションコーディネータが応答を受信し、
なしを
それぞれ取引を開始し、参加者に背をロールされ、参加者はトランザクションをロールバックし始めました。
図4は
、トランザクションコーディネータは、全員に返信、返信を受信
はい
、この時間は、トランザクションをコミットするために、参加者を開始します。参加者は、トランザクションをロールバックを開始する一方の当事者トランザクション・コーディネータによるトランザクションのコミットに失敗した場合。
2PCの利点：
- 強い整合性、リレーショナルデータベースのサポートの一部（達成オラクル、MySQLの、など）。
短所：
- トランザクション全体が複数のノード間で調整するコーディネーターの必要性、トランザクションの実行時間の増加、パフォーマンスの低下によって実行されます。
解決策があります。
springboot +
Atomikos
または
Bitronix
3PCは、
主に問題に起因し、ブロッキングコーディネーターと参加者のコミュニケーションを解決するために、それ以上である
2PCは
、さらにメッセージング、パフォーマンスは高くありません。詳細なリファレンス
3PC
：
https://en.wikipedia.org/wiki/Three-phase_commit_protocol
2.2トランザクション補償（TCC）
TCCの
トランザクション補償をベースに
2PC
ビジネス層のトランザクション制御プログラムの実装を、それは
試しに
、
Confifirm
や
キャンセル
三つの言葉の最初の文字は、次の意味があります。
1 、トライの検査や経営資源を保有します
完了したトランザクションを送信する前にチェックして、脇に優れたリソースを設定します。
2 、Confifirmは、動作を実行することを決定します
するために
しようと
、ステージは正式に実装されたリソースを禁じます。
3 、キャンセル、業務の実行をキャンセルします
するに
してみてください
リリースに段階予約リソースを。
次のように基本的なプロセスは次のとおりです。
説明するために、単一の事業例とマイナス在庫下：
1 、試してみてください
シングルビジネスコラボレーションは、注文サービスと在庫サービスによって行われ、
試す
段階の順序サービスと在庫サービスに脇の資源を見直し、設定を完了させます。
現在、（：現在、既存の受注残高は、新しい注文を送信することはできません例えば）を満たす注文を提出したサービスオーダの条件を確認してください。
十分な在庫、およびロックリソースが現在存在するかどうかをインベントリサービスチェック。
2 、Confifirm
注文サービスと在庫サービス正常終了
してみ
リソース操作の実装の正式開始後。
注文にメッセージの順序サービスの受注を書きます。
インベントリサービスマイナス在庫。
3 、キャンセル
ご注文の場合は、サービスおよびインベントリサービスはすべて1の当事者が操作をキャンセルするように見える失敗しています。
ご注文は、新しいサービスの注文情報を削除する必要があります。
インベントリサービスは、在庫を減算して、復元されます。
利点：
- 最終的にはビジネス層、良好な柔軟性を実現するために、データの整合性、トランザクション制御を保証します。
短所：
- 各参加者の取引あたりの高い開発コスト、操作が実装する必要があり、キャンセル/のtry / confifirmを3つのインタフェースを。
注：
TCC
さん
のtry / confifirm /キャンセル
のように、インタフェースが冪等を達成しなければならない
試み
、
confifirm
、
キャンセル
失敗後に再試行維持します。
冪等とは何ですか？
同じノー事項何回リクエストを参照するべき等の操作が、結果は同じです。
冪等操作の実装は、次のとおりです。
図1に示すように
決意動作は、ビジネス方法で実行する前に、もはや行われない場合。
2
、すべての要求の処理のキャッシュ要求と結果が直接結果を返すように処理されています。
3
未処理のデータ操作を処理するとき、プラスデータベーステーブル内のステータスフィールド（未処理、処理された）、その後に決定します。
最終と一貫2.3メッセージキューの実装
プログラムは、トランザクションを完了するために局所的に分散トランザクションの複数に分割され、そして以下に示すように、非同期メッセージキュー連携によって完成します。
説明するために、単一の例以下の在庫を減らします：
- 注文サービスと在庫のサービスは、検査及び予備リソースを完了します。
- ローカルトランザクション・レコードの順序完全なサービスとOrdersテーブルのアドオンを追加し、「インベントリタスクメッセージを減らします」。
- メッセージへのテーブルのタイミングによって送信された記録タスクMQ 通知サービスを行う減算在庫インベントリ操作。
- インベントリサービスの実行は、在庫を削減し、実行ステータスメッセージを記録する（回避リピートするためにメッセージを、このメッセージがマイナス在庫を実行する前に実行されたかどうかを確認）します。
- インベントリサービスMQは、在庫削減を完了するために、メッセージを送信します。
- 在庫削減の完了の知らせを受けた後に追加され、元の注文サービスを削除し、「インベントリタスクメッセージを減らすために」。
最後のトランザクションを達成するために一貫性の要件である：成功のための予備リソースには電源オンとを達成するために業務執行の方法を必要とし、再試行されます失敗した場合は、正式な理論が、成功している必要があり。
利点：
- MQ 非同期方法で、取引の完了、より高い性能を調整します。
- 実装せずに試してみる/ confifirm /キャンセルよりインターフェース開発コストTCCの低いを。
短所：
- ローカル・トランザクション・ベースのリレーショナルデータベースを達成するためのこの方法は、しばしばそこに読み取りと書き込みのデータベースレコードになる、高い同時動作に加えて、リソースのデータベース廃棄物ではなく、最良の選択肢。
