Zookeeper の分散トランザクションを理解していますか?

序文

皆さんはこんな状況に遭遇したことがあるでしょうか。何かを買うために食料品店に行き、支払いを済ませたのに、店主は他の用事を済ませていたため支払いを忘れてしまい、再度支払いを要求してきました。または、オンラインで買い物をすると、お金が引き落とされているのに、取引が行われていないと言われます。この一連の状況は、取引の不足によって発生します。これは人生における出来事の重要性をいくらか示しています。ビジネスを営んでいる場合、食料品店に何かを買うために行くときは、代金を支払って商品を受け取ります。トランザクションでは、オンラインで買い物をし、支払いを差し引くことで注文トランザクションが生成されます。

[[282777]]

取引の具体的な定義

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

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

酸

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

A: 原子性

トランザクション内のすべての操作は完了するか、まったく完了しないかのいずれかです。中間段階で終わることはありません。トランザクションの実行中にエラーが発生した場合、トランザクションが実行されなかったかのように、トランザクション開始前の状態にロールバックされます。

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

C: 一貫性

トランザクションの一貫性とは、トランザクションが実行される前と実行後にデータベースが一貫した状態にある必要があることを意味します。トランザクションが正常に完了すると、システム内のすべての変更が正しく適用され、システムは有効な状態になります。トランザクション中にエラーが発生した場合、システム内のすべての変更は自動的にロールバックされ、システムは元の状態に戻ります。

I: 孤立

これは、同時実行環境で、異なるトランザクションが同時に同じデータを操作する場合に、各トランザクションが独自の完全なデータ領域を持つことを意味します。同時実行トランザクションによって行われた変更は、他の同時実行トランザクションによって行われた変更から分離する必要があります。トランザクションがデータの更新を表示する場合、データは別のトランザクションによって変更される前の状態か、別のトランザクションによって変更された後の状態のいずれかになります。トランザクションは中間状態のデータは表示しません。

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

D: 耐久性

つまり、トランザクションが正常に終了する限り、データベースに対して行われた更新は永続的に保存される必要があります。システムクラッシュが発生した場合でも、データベースシステムを再起動することで、トランザクションが正常に終了した時点の状態にデータベースを復元できます。

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

InnoDB 実装の原則

InnoDB は MySQL のストレージ エンジンです。ほとんどの人は MySQL をよく知っています。ここでは、データベース トランザクション実装の基本原則について簡単に説明します。ローカル トランザクションでは、サービスとリソースはトランザクションのラッピングの下で​​ 1 つとして考えることができます。

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

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

UndoLog の原理は非常にシンプルです。トランザクションの原子性を満たすために、データを操作する前に、まずデータをある場所にバックアップする必要があります (データのバックアップが保存される場所は UndoLog と呼ばれます)。次にデータを変更します。エラーが発生した場合、またはユーザーが ROLLBACK ステートメントを実行した場合、システムは Undo ログ内のバックアップを使用して、トランザクションが開始される前の状態にデータを復元できます。

Undo Log とは異なり、RedoLog は新しいデータのバックアップを記録します。トランザクションがコミットされる前に、RedoLog を永続化するだけで十分であり、データを永続化する必要はありません。システムがクラッシュした場合、データは保持されませんが、RedoLog は保持されます。システムは、RedoLog の内容に基づいてすべてのデータを最新の状態に復元できます。具体的な実装プロセスに興味のある学生は、自分で拡張機能を検索できます。

分散トランザクション

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

分散トランザクションとは、トランザクション参加者、トランザクションをサポートするサーバー、リソース サーバー、およびトランザクション マネージャーが、異なる分散システムの異なるノードに配置されていることを意味します。簡単に言えば、大規模な操作はさまざまな小規模な操作で構成されています。これらの小さな操作は異なるサーバーに分散され、異なるアプリケーションに属します。分散トランザクションでは、これらの小さな操作がすべて成功するか、すべて失敗するかを保証する必要があります。本質的に、分散トランザクションは、異なるデータベース間でのデータの一貫性を確保するように設計されています。

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

上記のローカルトランザクションから、トランザクションが 2 つの部分に分かれていることがわかります。1 つはサービスが複数のノードを生成する部分、もう 1 つはリソースが複数のノードを生成する部分です。

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

インターネットの急速な発展に伴い、マイクロサービスや 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 つのフェーズに分かれています。

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

フェーズ 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 トランザクション メカニズムはいくつかの欠点を解決します。

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

3. データの一貫性。補償メカニズムでは、一貫性はビジネス アクティビティ マネージャーによって制御されます。

TCC の説明:

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

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

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

すべて成功したら確認し、100元の減額を確認して、ボトル入り飲料水を販売します。確認に失敗した場合は、失敗の内容に関係なく再試行します（再試行にはアクティビティ ログを使用します）

TCC には、次のようなものが適しています。

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

このソリューションの中核は、メッセージ ログを通じて分散処理を必要とするタスクを非同期的に実行することです。メッセージ ログはローカル テキスト、データベース、またはメッセージ キューに保存でき、ビジネス ルールを通じて再試行を自動または手動で開始できます。手動再試行は、調整システムを通じて後続の問題を処理するために支払いシナリオでよく使用されます。

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

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

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

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

4. 異常な状況が発生した場合、処理に失敗したメッセージは定期的にスキャンされ、再送信されます。製品サーバーはメッセージを受信すると、まずそれが重複しているかどうかを判断します。受信された場合は、それを実行するかどうかを判断します。実行されると、トランザクションに直ちに通知されます。実行されていない場合は再実行する必要があります。企業は、べき等性、つまり余分な水のボトルが差し引かれないことを保証する必要があります。

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

MQ トランザクション

分散トランザクションは、実際にはローカル メッセージ テーブルのパッケージである RocketMQ に実装されています。ローカル メッセージ テーブルは MQ の内部に移動されます。以下は MQ トランザクションの簡単な紹介です。さらに詳しく知りたい場合は、www.jianshu.com/p/453c6e7ff… を参照してください。

基本的なプロセスは次のとおりです。最初の段階では、準備されたメッセージがメッセージのアドレスを取得します。

2 番目のフェーズでは、ローカル トランザクションが実行されます。

3 番目のステージでは、最初のステージで取得したアドレスを通じてメッセージにアクセスし、ステータスを変更します。メッセージの受信者は、そのメッセージを使用できるようになります。

確認メッセージが失敗した場合、RocketMq Broker は更新されたステータスのないメッセージの時間指定スキャンを実行します。メッセージが確認されない場合、送信者にメッセージが送信され、送信されたかどうかが確認されます。 RocketMq では、メッセージは処理のためにリスナーの形式で送信者に送信されます。

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

サガトランザクション

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

各 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 は必要ありません。

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

100元で水のボトルを購入する例を見てみましょう。ここで定義する

T1 = 100元を減額 T2 = ユーザーに水のボトルを1本追加 T3 = 在庫を水のボトル1本分減らす

C1 = 100元を追加 C2 = ユーザーの水のボトルを1本減らす C3 = 在庫に水のボトルを1本追加

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

サガ モードでの分離の欠如が大きな影響を与えていることがわかります。 Huawei のソリューションを参考にしてください。ビジネス レベルから始めて、セッションとロック メカニズムを追加し、リソースをシリアル化できるようにします。また、資金を事前に凍結することでこれらのリソースをビジネス レベルで分離し、現在のステータスをタイムリーに読み取ることで、ビジネス運営中に最新の更新情報を取得することもできます。

やっと

繰り返しますが、分散トランザクションを回避できる場合は、使用しないでください。これらを使用する必要がある場合は、独自のビジネスを分析し、強力な一貫性と最終的な一貫性のどちらを重視するかにかかわらず、どちらがビジネスに適しているかを確認してください。上記のソリューションは、簡単な紹介にすぎません。実際に実装しようとすると、ソリューションごとに考慮すべき点が多く、複雑さも比較的大きくなります。最後に、分散トランザクションを使用するかどうかについて適切な判断を下すよう再度お願いしたいと思います。