1. 地方事情
ローカル トランザクションは従来のスタンドアロン トランザクションです。従来のデータベース トランザクションでは、次の 4 つの原則を満たす必要があります。
2. 分散トランザクション
分散トランザクションは、単一のサービスまたは単一のデータベース アーキテクチャの下で生成されないトランザクションを指します。
データソース間の分散トランザクション
サービス間での分散トランザクション
総合的な状況
データベースの水平分割とサービスの垂直分割の後、通常、ビジネス オペレーションは複数のデータベースとサービスにまたがって完了する必要があります。たとえば、電子商取引業界でより一般的な注文支払いケースには、次のような動作が含まれます。
新しい注文を作成する
製品在庫を差し引く
ユーザーアカウント残高から差し引かれる金額
上記の操作を完了するには、3 つの異なるマイクロサービスと 3 つの異なるデータベースにアクセスする必要があります。
注文の作成、在庫の控除、およびアカウントの控除は、各サービスとデータベース内のローカル トランザクションであり、ACID 原則が保証されます。
しかし、3 つのことを「ビジネス」とみなす場合、「ビジネス」の原子性を確保する必要があります。すべての操作が成功するか、すべて失敗するかのどちらかです。部分的な成功と部分的な失敗は許可されません。これは 。 トランザクション
現時点では ACID を満たすことが難しく、分散トランザクションで解決しなければならない問題です。
1.3. 分散トランザクションの問題をデモンストレーションする
分散トランザクションの問題を示すためにケースを使用します。
1)seata_demo という名前のデータベースを作成し、SQL ファイルをインポートします。
リンク: https://pan.baidu.com/s/10bd7RX9lXqIDlMODMOyV4Q?pwd=3l4o
抽出コード: 3l4o
--Baidu よりNetdisk Super Member V6 の共有
2)マイクロサービスをインポートする:
リンク: https://pan.baidu.com/s/1tB_c5KbskqGfFLP-phC0dQ?pwd=tgvp
抽出コード: tgvp
-- Baidu Netdisk スーパー メンバー V6 からの共有
マイクロサービスの構造は次のとおりです。
で：
Seata-demo: 親プロジェクト。プロジェクトの依存関係の管理を担当します。
account-service: ユーザーの資本口座の管理を担当するアカウント サービス。残高を控除するためのインターフェイスを提供します
storage-service: 製品在庫の管理を担当する在庫サービス。在庫を差し引くためのインターフェイスを提供します
order-service: 注文サービス。注文の管理を担当します。注文を作成するときは、account-service と storage-service を呼び出す必要があります。
3) nacos とすべてのマイクロサービスを開始します
4) 注文関数をテストし、Post リクエストを発行します。
テストの結果、在庫が不足している場合、残高が差し引かれているとロールバックされず、分散トランザクションの問題が発生することがわかりました。 (各ブランチのトランザクションは相互に認識しておらず、それぞれが独自のトランザクションをコミットするため、ロールバックすることはできません)
3. 理論的根拠
分散トランザクションの問題を解決するには、理論的な指針として分散システムの基本的な知識が必要です。
3.1.CAP定理
1998 年、カリフォルニア大学のコンピューター科学者エリック ブリュワーは、分散システムには 3 つの指標があると提案しました。
一貫性
可用性
パーティション許容度
それらの最初の文字はそれぞれ C、A、P です。
Eric Brewer 氏は、これら 3 つの指標を同時に達成することは不可能です (同時に最大 2 つ) と述べました。この結論は CAP 定理と呼ばれます。
3.1.1.一貫性
一貫性: ユーザーが分散システム内のノードにアクセスする場合、取得されるデータは一貫性がなければなりません。
たとえば、現在 2 つのノードが含まれており、それらの初期データは一貫しています。
いずれかのノードのデータを変更すると、2 つのノードのデータは異なります。
一貫性を維持するには、node01 から node02 へのデータ同期を達成する必要があります。
3.1.2. 可用性
可用性: クラスタ内の正常なノードにアクセスするユーザーは、タイムアウトや拒否ではなく応答を取得できる必要があります。
図に示すように、3 つのノードを持つクラスターでは、どのノードにアクセスしてもタイムリーな応答を得ることができます。
ネットワーク障害またはその他の理由により一部のノードにアクセスできない場合は、そのノードが使用できないことを意味します。
3.1.3. パーティションのフォールトトレランス
パーティション: ネットワーク障害またはその他の理由により、分散システム内の一部のノードが他のノードとの接続を失い、独立したパーティションを形成します。
耐性: クラスタ内でパーティションが発生した場合、システム全体が外部にサービスを提供し続ける必要があります
3.1.4.矛盾
分散システムでは、システム間のネットワークの健全性を 100% 保証することはできず、必ず障害が発生するため、外部に対してサービスを保証する必要があります。したがって、パーティショントレランスは避けられません。
ノードが新しいデータ変更を受信すると、問題が発生します。
この時点で一貫性を確保したい場合は、ネットワークが回復するまで待つ必要があります。データの同期が完了すると、全体のクラスタは外部にサービスを提供できますが、ブロッキング状態で利用できません。
現時点で可用性を確保したい場合は、ネットワークが回復するまで待つことはできません。回復すると、node01 間にデータの不整合が発生します。 、node02、node03。
つまり、Pが必ず現れるという条件では、AとCのどちらか一方しか実現できません。
3.2.BASE理論（矛盾の調整）
BASE 理論は CAP の解決策であり、3 つのアイデアが含まれています。
基本的に利用可能 (基本的に利用可能): 分散システムで障害が発生した場合、部分的な可用性が失われることが許容されます。コアの可用性が保証されています。
ソフト状態: 一定期間内では、一時的な矛盾した状態などの中間状態が許可されます。
最終的に整合性: 強力な整合性は保証できませんが、ソフト状態が終了した後は最終的にデータの整合性が達成されます。
4. 分散トランザクションを解決するためのアイデア
分散トランザクションの最大の問題は、各サブトランザクションの一貫性です。したがって、CAP 定理と BASE 理論から学ぶことができます。解決策は 2 つあります。
AP モード: 各サブトランザクションは個別に実行および送信されるため、一貫性のない結果が発生する可能性があり、最終的な整合性を達成するためにデータを復元するための是正措置を講じます。
CP モード: 各サブトランザクションは実行後に相互に待機し、同時にコミットし、同時にロールバックして、強整合性を実現します。ただし、トランザクションが待機している間は、可用性が低い状態になります。
ただし、どのモードであっても、サブシステム トランザクション間で相互に通信し、トランザクション ステータスを調整する必要があります。これは、トランザクション コーディネーター (TC)
ここでのサブシステム トランザクションはブランチ トランザクションと呼ばれます。関連するブランチ トランザクションをまとめてグローバル トランザクションと呼ばれます。 。
気に入っていただけましたら、ぜひフォローをお願いします！
