コレクション | 「分散トランザクション」をこれほどシンプルかつ明確に説明した人は初めてだ

[[239975]]

または、オンラインで買い物をすると、お金が引き落とされているのに、取引が行われていないと言われます。この一連の状況は、取引の不足によって発生します。これは人生における出来事の重要性をいくらか示しています。

ビジネスを営んでいる場合、食料品店に何かを買うために行くときは、代金を支払って商品を受け取ります。トランザクションでは、オンラインで買い物をし、支払いを差し引くことで注文トランザクションが生成されます。

取引の具体的な定義

トランザクションは、アクティビティに関係するすべての操作を分割できない実行単位に組み込むメカニズムを提供します。トランザクションを構成するすべての操作は、すべての操作が正常に実行できる場合にのみコミットできます。いずれかの操作の実行に失敗した場合、トランザクション全体がロールバックされます。

簡単に言えば、トランザクションは「すべてか無か」のメカニズムを提供します。

データベースのローカルトランザクション

酸

データベース トランザクションに関しては、データベース トランザクションにおける ACID の 4 つの主要な特性について説明する必要があります。

A: 原子性です。トランザクション内のすべての操作は完了するか、まったく完了しません。それらは中間段階で終わることはありません。

トランザクションの実行中にエラーが発生した場合、トランザクションが実行されなかったかのように、トランザクション開始前の状態にロールバックされます。

何かを購入するときと同じように、支払いと商品受け取りを同時に行うか、商品を発送できない場合は返金を受けることができます。

C: 一貫性。トランザクションの一貫性とは、トランザクションが実行される前と実行後にデータベースが一貫した状態にある必要があることを意味します。

トランザクションが正常に完了すると、システム内のすべての変更が正しく適用され、システムは有効な状態になります。

トランザクション中にエラーが発生した場合、システム内のすべての変更は自動的にロールバックされ、システムは元の状態に戻ります。

I: 分離とは、同時実行環境において、異なるトランザクションが同時に同じデータを操作する場合に、各トランザクションが独自の完全なデータ領域を持つことを意味します。

同時実行トランザクションによって行われた変更は、他の同時実行トランザクションによって行われた変更から分離する必要があります。トランザクションがデータの更新を表示する場合、データは別のトランザクションによって変更される前の状態か、別のトランザクションによって変更された後の状態のいずれかになります。トランザクションは中間状態のデータは表示しません。

たとえば、何かを購入しても他の人には影響しません。

D: 永続性とは、トランザクションが正常に終了する限り、データベースに対して行われた更新が完全に保存されることを意味します。

システムクラッシュが発生した場合でも、データベースシステムを再起動することで、トランザクションが正常に終了した時点の状態にデータベースを復元できます。

例えば、何かを買ったときは、それを帳簿に記録しておく必要があります。そうすれば、上司が忘れても証拠が残ります。

InnoDB 実装の原則

InnoDB は MySQL のストレージ エンジンです。ほとんどの人は MySQL をよく知っています。ここでは、データベース トランザクション実装の基本原則を簡単に紹介します。

ローカル トランザクションでは、次の図に示すように、サービスとリソースはトランザクションのラッピングの下で​​ 1 つのエンティティとして考えることができます。

ローカル トランザクションはリソース マネージャーによって管理されます。

トランザクションの ACID は、InnoDB ログとロックによって保証されます。トランザクションの分離はデータベース ロック メカニズムによって実現され、永続性は Redo ログによって実現され、原子性と一貫性は Undo ログによって実現されます。

Undo Log の原理は非常にシンプルです。トランザクションの原子性を満たすために、データを操作する前に、データをある場所にバックアップする必要があります (データのバックアップが保存される場所は Undo ログと呼ばれます)。次にデータを変更します。

エラーが発生した場合、またはユーザーが Rollback ステートメントを実行した場合、システムは Undo ログ内のバックアップを使用して、トランザクションが開始される前の状態にデータを復元できます。

Undo ログとは異なり、Redo ログは新しいデータのバックアップを記録します。トランザクションがコミットされる前に、REDO ログを永続化するだけで十分であり、データを永続化する必要はありません。

システムがクラッシュした場合、データは保持されませんが、REDO ログは保持されます。システムは、REDO ログの内容に基づいてすべてのデータを最新の状態に復元できます。具体的な実装プロセスに興味のある学生は、自分で拡張機能を検索できます。

分散トランザクション

分散トランザクションとは何か

分散トランザクションとは、トランザクション参加者、トランザクションをサポートするサーバー、リソース サーバー、およびトランザクション マネージャーが、異なる分散システムの異なるノードに配置されていることを意味します。

簡単に言えば、大規模な操作はさまざまな小規模な操作で構成されています。これらの小さな操作は異なるサーバーに分散され、異なるアプリケーションに属します。分散トランザクションでは、これらの小さな操作がすべて成功するか、すべて失敗するかを保証する必要があります。

本質的に、分散トランザクションは、異なるデータベース間でのデータの一貫性を確保するように設計されています。

分散トランザクションの原因

上記の地域情勢は、次の 2 つの部分に分けることができます。

• サービスは複数のノードを生成する
• リソースは複数のノードを生成する

複数のノードをサービスする

インターネットの急速な発展に伴い、マイクロサービスや SOA などのサービス アーキテクチャ モデルが大規模に使用されるようになりました。

簡単な例を挙げると、企業内では、ユーザーの資産が残高、ポイント、クーポンなどの多くの部分に分割される場合があります。

企業内では、ポイント機能は 1 つのマイクロサービス チームによって管理され、クーポンは別のチームによって管理される場合があります。

この場合、ポイントが減算された後にクーポンが正常に減算される保証はありません。

リソース複数のノード

同様に、インターネットは急速に発展しており、最も人気のあるデータを保存するために、MySQL を個別のライブラリとテーブルに分割する必要があります。

Alipay 送金サービスの場合、友人に送金する際、あなたのデータベースは北京にあり、友人のお金は上海にある可能性があります。そのため、送金が同時に成功することを保証することはできません。

分散トランザクションの基礎

上記から、分散型トランザクションはインターネットの急速な発展とともに誕生したことがわかります。これは避けられないことだ。

前にも述べたように、データベースの 4 つの ACID 特性はもはや分散トランザクションに対応できません。現時点では、何人かの新しい大物がいくつかの新しい理論を提唱している。

キャップ

CAP 定理、ブリューワーの定理とも呼ばれます。分散システム (分散トランザクションだけではない) を設計するアーキテクトにとって、CAP は入門理論となります。

C (一貫性): 特定のクライアントの場合、読み取り操作は書き込み操作と同じ結果を返します。

異なるノードに分散されたデータについて、あるノードでデータが更新された場合、他のノードが最新のデータを読み取ることができる場合、それは強力な一貫性と呼ばれます。特定のノードが読み取れない場合は、分散不整合となります。

A (可用性): 障害のないノードは、妥当な時間内に妥当な応答 (エラーやタイムアウトではない) を返します。可用性の鍵となるのは、適切な時間と適切な応答の 2 つです。

合理的な時間とは、リクエストを完全にブロックすることはできず、合理的な時間内に返却する必要があることを意味します。合理的な応答とは、システムが明確に結果を返し、その結果が正しいことを意味します。ここでの正しいとは、たとえば、40 ではなく 50 を返す必要があることを意味します。

P (パーティション耐性): ネットワーク パーティションが発生してもシステムは動作を継続できます。たとえば、クラスター内に複数のマシンがあり、そのうちの 1 台のマシンにネットワークの問題が発生しても、クラスターは正常に動作します。

CAP に詳しい人なら誰でも、これら 3 つは共存できないことを知っています。ご興味があれば、CAP の証明を検索してみてください。分散システムでは、ネットワークは 100% 信頼できるわけではなく、パーティショニングは実際には避けられない現象です。

CA を選択して P を放棄した場合、分割が発生したときに一貫性を確保するために、この時点で要求を拒否する必要がありますが、A はそれを許可しません。したがって、理論上、分散システムでは CA アーキテクチャを選択することは不可能であり、CP または AP アーキテクチャのみを選択できます。

CP では、可用性を放棄し、一貫性とパーティション耐性を追求します。私たちの ZooKeeper は実際に強力な一貫性を追求しています。

AP の場合、一貫性 (ここでの一貫性は強い一貫性を指します) を放棄し、パーティション耐性と可用性を追求することが、多くの分散システム設計の選択肢となります。後続のBASEもAPに基づいて拡張されます。

ちなみに、CAP理論ではネットワーク遅延は無視されます。つまり、トランザクションがコミットされると、ノードAからノードBへのコピーに遅延は発生しません。ただし、これは現実には明らかに不可能であるため、常に一定の不整合が発生します。

同時にCAPから2つ選択します。たとえば、CP を選択した場合、A を放棄しなければならないわけではありません。P が出現する確率は非常に小さいため、ほとんどの場合、CA を確保する必要があります。

パーティションが発生した場合でも、何らかのログ手段を使用して他のマシンを使用可能な状態に復元するなど、後で A に備える必要があります。

ベース

BASE は、Basically Available、Soft state、Eventually Consistent の 3 つのフレーズの略語であり、CAP の AP の拡張です。

基本的な可用性: 分散システムに障害が発生した場合、コア機能の可用性を確保するために、利用可能な機能の一部が失われることが許容されます。

ソフト状態: システム内の中間状態の存在を許可しますが、システムの可用性には影響しません。ここでは、CAP の不一致について言及しています。

最終的な一貫性: 最終的な一貫性とは、一定期間が経過すると、すべてのノード データが一貫した状態になることを意味します。

BASE は、CAP における理論上のネットワーク遅延がないという問題を解決します。 BASE はソフト ステートおよび結果整合性を使用して、遅延後の一貫性を保証します。

BASE は ACID の反対です。これは、ACID の強力な一貫性モデルとはまったく異なります。代わりに、強力な一貫性を犠牲にして可用性を獲得し、一定期間データの不整合を許容しますが、最終的には一貫した状態に到達します。

分散トランザクションソリューション

上記の理論的基礎を踏まえて、ここではいくつかの一般的な分散トランザクション ソリューションを紹介していきます。

本当に分散トランザクションが必要ですか?

ソリューションについて話す前に、まず分散トランザクションが本当に必要かどうかを明確にする必要があります。

上で述べた分散トランザクションが発生する 2 つの理由のうち、1 つはマイクロサービスが多すぎることです。 1 人の人間が複数のマイクロサービスを管理しているチームや、過剰なエンジニアリングを行って全員を疲弊させているチームを私は数多く見てきました。

マイクロサービスが多すぎると、トランザクションが分散されます。現時点では、以下の解決策を採用することはお勧めしません。代わりに、トランザクションを必要とするマイクロサービスを単一マシンのサービスに集約し、データベースのローカル トランザクションを使用してください。

どのようなソリューションでもシステムの複雑さが増すため、コストが非常に高くなります。特定のデザインを追求するからといって、不必要なコストや複雑さを導入しないでください。

分散トランザクションを導入する必要があることが確実な場合は、次の一般的なソリューションを検討してください。

2PC

2PC について話すときは、データベース分散トランザクションにおける XA トランザクションについて話す必要があります。

XA プロトコルは 2 つのフェーズに分かれています。

• トランザクション マネージャーは、トランザクションに関係する各データベースに対して、操作を事前にコミットし、コミットできるかどうかを反映することを要求します。
• トランザクション コーディネーターは、各データベースにデータをコミットするか、データをロールバックするかを要求します。

アドバンテージ：

• 低い実装コストで強力なデータ一貫性を確保するよう努めています。当社はこれをすべての主要データベースに実装しており、MySQL のサポートは 5.5 以降で提供されています。

欠点:

• 単一点の問題: トランザクション マネージャーは、プロセス全体において重要な役割を果たします。たとえば、最初のステージが完了し、2 番目のステージを送信しようとしているときにクラッシュすると、トランザクション マネージャーがクラッシュし、リソース マネージャーがブロックされ、データベースが使用できなくなります。
• 同期ブロッキング: 準備完了後、リソース マネージャー内のリソースは、送信が完了してリソースが解放されるまでブロックされます。
• データの不整合: 2 フェーズ コミット プロトコルは分散データの強力な一貫性を実現するように設計されていますが、それでもデータの不整合が発生する可能性があります。

たとえば、第 2 フェーズでは、コーディネーターがトランザクション コミット通知を送信したが、ネットワークの問題により、通知は一部の参加者によってのみ受信され、コミット操作が実行されるものとします。残りの参加者は通知を受信して​​いないためブロックされ、データの不整合が発生します。

一般に、XA プロトコルは比較的単純で低コストですが、単一点の問題と、高い同時実行性をサポートできないこと (同期ブロッキングによる) が依然として最大の弱点となっています。

TCC

TCC (Try-Confirm-Cancel) の概念は、2007 年に公開された「Life beyond Distributed Transactions: an Apostate's Opinion」と題された論文で Pat Helland によって初めて提案されました。

上記の XA と比較して、TCC トランザクション メカニズムは次の欠点を解決します。

• 単一のコーディネータ ポイントが解決され、ビジネス アクティビティは主要なビジネス パーティによって開始され、完了されます。 Business Activity Manager もマルチポイントになり、クラスターが導入されます。
• 同期ブロッキング: タイムアウトが導入され、タイムアウト後に補正が実行され、リソース全体がロックされません。リソースは、より細かい粒度のビジネス ロジック形式に変換されます。
• 補正メカニズムによるデータの一貫性は、ビジネス アクティビティ マネージャーによって制御されます。

TCC の説明:

• 試行フェーズ: 実行を試行し、すべてのビジネス チェックを完了し (一貫性)、必要なビジネス リソースを予約します (準分離)。
• 確認フェーズ: ビジネスチェックを行わずに、ビジネスの実際の実行を確認します。試行フェーズで予約されたビジネス リソースのみが使用されます。確認操作は冪等性を満たします。べき等設計が必要であり、確認が失敗した後は再試行が必要です。
• キャンセル ステージ: 実行をキャンセルし、Try ステージで予約されたビジネス リソースを解放します。キャンセル操作はべき等性を満たします。キャンセル フェーズでの例外処理ソリューションは、基本的に確認フェーズでのソリューションと同じです。

簡単な例を挙げてみましょう。100 元を使って水のボト​​ルを購入する場合、試用段階：財布に 100 元があるかどうかを確認し、100 元をロックする必要があります。水についても同じことが言えます。

失敗した場合はキャンセルが実行されます（100元と水のボトルが解放されます）。キャンセルが失敗した場合は、失敗に関係なくキャンセルを再試行するため、べき等性を維持する必要があります。

すべて成功した場合は、100 元が差し引かれ、水のボトルが販売されたことを確認します。確認が失敗した場合は、失敗に関係なく再試行します (再試行はアクティビティ ログに依存します)。

TCC の場合、次のようになります。

• 強力な分離性と厳格な一貫性要件を備えたアクティビティ。
• 実行時間が短いビジネス。

実装リファレンス: https://github.com/liuyangming/ByteTCC/。

ローカルメッセージテーブル

ローカル メッセージ テーブル ソリューションは、もともと eBay によって提案されました。 eBay の完全なソリューションは https://queue.acm.org/detail.cfm?id=1394128 です。

このソリューションの中核は、メッセージ ログを通じて分散処理を必要とするタスクを非同期的に実行することです。メッセージ ログはローカル テキスト、データベース、またはメッセージ キューに保存でき、ビジネス ルールを通じて再試行を自動または手動で開始できます。

手動再試行は、調整システムを通じて後続の問題を処理するために支払いシナリオでよく使用されます。

ローカル メッセージ キューの場合、コアとなるのは、大規模なトランザクションを小規模なトランザクションに変換することです。 100元を使って水のボト​​ルを買うという上記の例を見てみましょう。

1. お金を差し引く場合、お金を差し引くサーバー上に新しいローカル メッセージ テーブルを追加する必要があります。差し引いた金額と水を除いた在庫をローカル メッセージ テーブルに書き込み、同じトランザクションに配置する必要があります (一貫性を確保するためにデータベースのローカル トランザクションに依存します)。

2. この時点で、ローカル トランザクション テーブルをポーリングし、未送信メッセージを商品在庫サーバーにスローして、水在庫を減算するように要求するスケジュールされたタスクがあります。商品サーバーに到着したら、まずこのサーバーのトランザクション テーブルに書き込まれ、その後に減算が実行されます。控除が成功すると、取引テーブル内のステータスが更新されます。

3. 製品サーバーは、スケジュールされたタスクを通じてメッセージ テーブルをスキャンするか、または控除サーバーに直接通知し、控除サーバーはローカル メッセージ テーブル内のステータスを更新します。

4. 異常な状況が発生した場合、処理に失敗したメッセージは定期的にスキャンされ、再送信されます。製品サーバーはメッセージを受信すると、まずそれが重複しているかどうかを判断します。

受信された場合は、実行するかどうかを判断します。実行された場合は、直ちにトランザクションを通知します。実行されていない場合は、ビジネスのべき等性を保証するために、つまり余分な水のボトルが差し引かれないようにするために、再実行する必要があります。

ローカル メッセージ キューは BASE 理論に基づいており、一貫性の要件が高くない状況に適した、最終的に一貫性のあるモデルです。このモデルを実装するときは、再試行のべき等性に注意する必要があります。

MQ トランザクション

RocketMQ に実装されている分散トランザクションは、実際にはローカル メッセージ テーブルのラッパーであり、ローカル メッセージ テーブルを MQ に移動します。

以下は MQ トランザクションの簡単な紹介です。さらに詳しく知りたい場合は、https://www.jianshu.com/p/453c6e7ff81c を参照してください。

基本的なプロセスは次のとおりです。

• *** ステージでは、準備されたメッセージはメッセージのアドレスを取得します。
• 2 番目のフェーズでは、ローカル トランザクションが実行されます。
• 第 3 段階では、第 1 段階で取得したアドレスを使用してメッセージにアクセスし、ステータスを変更します。メッセージの受信者は、そのメッセージを使用できるようになります。

確認メッセージが失敗した場合、RocketMQ Broker は更新されたステータスのないメッセージのスケジュールされたスキャンを提供します。

メッセージが確認されない場合、送信者にメッセージが送信され、送信されたかどうかが確認されます。 RocketMQ では、処理のためにリスナーの形式で送信者に渡されます。

消費がタイムアウトした場合は継続的に再試行する必要があり、メッセージの受信側ではべき等性を確保する必要があります。メッセージの消費が失敗した場合は、手動処理が必要になります。これが起こる確率は低いため、この小さな確率のためだけに複雑なプロセスを設計するのは逆効果になります。

サガトランザクション

Saga は、30 年前のデータベース倫理に関する記事で言及された概念です。基本的な考え方は、長いトランザクションを複数のローカルの短いトランザクションに分割し、それらを Saga トランザクション コーディネータが調整することです。正常に終了した場合は正常に完了します。ステップが失敗した場合、補正操作が逆の順序で 1 回呼び出されます。

Saga の構成: 各 Saga は一連のサブトランザクション Ti で構成されます。各 Ti には対応する補正アクション Ci があり、これは Ti によって発生した結果を元に戻すために使用されます。ここでの各 T はローカル トランザクションです。

TCC と比較すると、Saga には「予約された try」アクションがなく、Ti が直接ライブラリに送信されることがわかります。

Saga には 2 つの実行順序があります。

• T1、T2、T3、…、Tn。
• T1、T2、...、Tj、Cj、...、C2、C1、ただし0 < j < n。

Saga は 2 つの回復戦略を定義しています。

• 後方回復、つまり上記の 2 番目の実行順序 (j はエラーが発生したサブトランザクション) は、それ以前の成功したサブトランザクションをすべてキャンセルする効果があり、したがって Saga 全体の実行結果をキャンセルします。
• フォワードリカバリは、成功が必須のシナリオに適用できます。実行順序は次のようになります: T1、T2、...、Tj (失敗)、Tj (再試行)、...、Tn。ここで、j はエラーが発生したサブトランザクションです。この場合、Ci は必要ありません。

ここで注意すべき点は、Saga モードではリソースがロックされず、他のトランザクションが現在のトランザクションを上書きしたり影響を与えたりする可能性があるため、分離は保証されないということです。

100元で水のボトルを買う例を見てみましょう。定義は次のとおりです。

• T1 = 100 元を減額、T2 = ユーザーに水のボトルを 1 本追加、T3 = 在庫を水のボトル ​​1 本分減らします。
• C1 = 100 元を追加、C2 = ユーザーから水のボトル ​​1 本を減算、C3 = 在庫に水のボトル ​​1 本を追加。

T1、T2、T3 を 1 つずつ実行します。問題が発生した場合、問題の原因となった C 操作の逆の操作を実行します。

上記の分離問題は、T3 でロールバックが必要になったが、ユーザーがすでに水を飲んでいる (別のトランザクションで) 場合に発生する可能性があります。ロールバックを実行すると、ユーザーは水のボトルを入手できないことがわかります。

これは、トランザクション間の分離がないことによる問題です。 Saga モードでの分離の欠如が依然として大きな影響を与えていることがわかります。 Huawei のソリューションを参考にしてください。ビジネス レベルから始めて、セッションとロック メカニズムを追加し、リソースをシリアル化できるようにします。

また、資金を事前に凍結することで、これらのリソースを業務レベルで分離することも可能であり、顧客は業務運営中に現在の状況をタイムリーに読み取って最新情報を入手することができます。 （具体例：Huaweiのサービスコームをご参照ください）

***

繰り返しますが、分散トランザクションを回避できる場合は、使用しないでください。これらを使用する必要がある場合は、独自のビジネスを分析し、強力な一貫性と最終的な一貫性のどちらを重視するかにかかわらず、どちらがビジネスに適しているかを確認してください。

***要約すると、記事にはいくつかの疑問が見つかります。

• ACID と CAP の CA は同じですか?
• 分散トランザクションに一般的に使用されるソリューションの利点と欠点は何ですか?どのようなシナリオに適していますか?
• 分散トランザクションが出現した理由は何ですか?どのような問題点を解決するために使われますか?