すべての記事
https://www.cnblogs.com/lay2017/p/12078232.html
テキスト
では、取引の基本的な考え方 1件の記事で、私たちは、トランザクションはACIDの四つの基本的な性質を満たさなければならないことを知っています。あなたがプログラムはACID特性を満たすために、トランザクションの特性を提供したい場合は、規範の一部に準拠して試してみて下さい。十分な容量がある場合はもちろん、あなたはまた、仕様の一部をカスタマイズすることができます。
この記事では、比較的単純な段階（1個）、トランザクションがコミットプロトコルについて学習します。
1個のトランザクションがコミットプロトコル
図のシーケンスを初めて目。
2相コミット部分のみです
1）トランザクションを開きます
2）通常のトランザクション、または例外をコミットしたときにロールバック情勢
1個の利点は非常に明白です。パフォーマンスは比較的良好であるので、非常に単純な、ただ、インタラクティブ大幅に少ない上、損失をサーバーとの対話を維持します。
そしてそれはまた、非常に明らかな欠点です。複数のサーバーであれば、複数のサーバーを調整することができないとき。そのため、シナリオの使用は、より限定されています。
このような外観は、プロトコルが似ていないコミット1PC 事項のデザインインターフェイスJDBCそれ？
1個でそのハンドルの複数のサーバーを仮定？
以前、我々は、単一のサーバーの場合に、より適し個と述べました。それはより多くのサービス側よりもある場合は、複数のサーバー側1PCトランザクションを調整することはできません。
そこで、我々は次のようになり、複数のサーバーを扱う1個と仮定しますか？
私たちは、その後、問題なく成功した場合は、すべての方法をコミットすることアクティビティ図は、3つのトランザクションを開き、参照してください。
1が失敗した場合、現在のトランザクションをロールバックし、人間の介入前の取引から生じた必要なデータの不整合を提出しました。
もちろん、いくつかのシナリオでは、我々はそれが（例えばMQ用、メッセージを送信することは、繰り返し送信することができます維持するために、メッセージの冪等を消費します。とMQケースがコミット障害がまれに発生成功するまで、コミット再試行を継続することを選択できますでも比較的容易に回復すること）もあります。しかし、ほとんどのシナリオでは、明らかに1個複数のデータソースには適していません。
概要
私たちは1個のトランザクションを選択するシナリオは、プロトコルは、シンプルかつ効率的なソリューションであるコミットのみ、次のデータソースの場合我々は、そう思うことができ、または我々は（最終的な一貫性を維持するために）コミットを再試行し続けることができます。