Goで実装された分散トランザクションフレームワークのパート2

[[440473]]

この記事はWeChatの公開アカウント「RememberGo」から転載したもので、著者はWu Qin Curryです。この記事を転載する場合はRememberGo公式アカウントまでご連絡ください。

導入

前回の記事では、Goで実装された分散トランザクションフレームワークであるseata-golangを中心に紹介しました。 Seata に匹敵する Go 言語実装ですが、もちろんバージョンはまだ Java バージョンよりはるかに遅れています。

今回は、Go で実装された別の分散トランザクション、dtm を紹介します。

まずは、dtmの全体的なアーキテクチャ図を見てみましょう（公式サイトより）。

先ほどの seata のアーキテクチャ図をもう一度見てみましょう。

建築の観点から見ると、ほぼ同じです。

seata の TC は dam の TM に対応します。

RM 双方とも同意します。

seata の TM は、dtm トランザクション SDK に相当します。機能は同じです。最初の段階では、グローバルトランザクションが開始され、各 RM ブランチトランザクションが実行されます。第２段階では、RMの第１段階の実行結果に応じて、TC(seata)を呼び出すことを決定する。| TM (dtm) コミットまたはロールバック。

アーキテクチャの面では、モジュール名と画像だけが異なっていると個人的に感じています。もちろん、実装の詳細にはまだ大きな違いがあります。

まず、DTM の各モジュールについて簡単に紹介します。

TM

TM レイヤーのコードには特定のメイン構造はなく、すべては関数の前の呼び出しから始まります。

TM を起動すると、実際には http と grpc の 2 つのサービスが起動します。

httpルーティング、

gRPCインターフェース、

サービスエントランスが2つあるので、コア業務をこなすパブリックな部分は当然あるはずです。

TM のデータストレージ管理は、インターフェイスではなく、common.DB 構造に依存します。基盤となるデータベースは、構成ファイルの DB.driver の値に応じて、mysql または postgres のいずれかになります。

改めてDB構造を見てみると、下層でどのようなデータベースが使われているかに関係なく、データの操作は直接gormに依存しています。

次に、TM が各 RM にコミットまたはロールバックを通知する方法を見てみましょう。

TCC モデルの例を見てみましょう。

TCC の 2 つのステージ。

ステージ1: 試してみる。実行を試行し、各 RM によってカスタマイズされた try 動作を呼び出し、必要なビジネスリソースを予約します。
フェーズ 2: 確認 (フェーズ 1 でこのトランザクションに参加しているすべての試行動作が成功します)。各ブランチトランザクションの Confirm メソッドを呼び出して実際にビジネスを実行し、try フェーズで予約されたリソースのみを使用します。
フェーズ 2: キャンセル (フェーズ 1 でこのトランザクションに参加したすべての try 動作が失敗します)。各ブランチトランザクションの Cancel メソッドを呼び出して、try の最初のフェーズ用に予約されたリソースを解放します。

上記から、TCC モードでは、TM が第 2 フェーズで各ブランチトランザクションに確認またはキャンセルを通知することがわかります。

各 RM トランザクションブランチを TM に登録すると、TM は最終的に分散トランザクションの参加者 (RM) ごとに 2 つのブランチ情報を生成します。

このように、

はい、対応する RM リソース操作アドレスを直接保存するだけです。

TM は、コミットまたはロールバックコマンドを受信すると、独自のロジック (通常は Gloable ステータスの変更) を処理した後、登録されている各ブランチトランザクションの処理を開始する必要があります。簡単に言えば、各ブランチトランザクションの操作に対応するインターフェースを呼び出す必要があります。

ここで、t.getProcessor() は、論理処理を実行するために、現在のトランザクションのタイプ (TCC、SAGA、XA) に応じて対応するプロセッサを取得する必要があります。

もちろん、各トランザクションプロセッサはインターフェースを実装するだけで済みます。

実際に RM リソースサービスのアドレスを呼び出す場合、http と grpc に分かれており、どちらになるかは開発者によって決まります。

v1.6 より前のバージョンでは、grpc リクエストは単にアドレスを解析して接続するだけの大雑把な方法でした。

現在、gRPC リゾルバメカニズムを使用する一部のマイクロサービスフレームワークのアクセスをサポートするために、抽象化が行われています。興味のある方は[1]をご覧ください。ここでは紹介しません。

開発キット

SDK に関しては、各トランザクションモードは独立しており、本質的に無関係です。たとえば、以下のように TCC 分散トランザクションを開始してみましょう。この分散トランザクションは、+30 サービスと -30 サービスと呼ばれる 2 つのサービスで構成されます。

上記の呼び出しから、プロセス全体を復元できます。
分散IDを取得するにはTMを呼び出します
分散トランザクションを開始するには、TccGlobalTransaction 関数を呼び出します。
TM prepare を呼び出します (このステップは、最初のステップで生成された分散トランザクションステータスが準備中であるかどうかを確認するだけです。ここがわかりません。実行ブランチはこの時点では登録されていません。グローバルステータスは初期化ステータスにのみ存在するべきではないでしょうか?)
前のステップは問題ありません。渡されたクロージャ関数、つまり CallBranch 関数で TM にトランザクションを登録する TM ブランチが実行されます。登録が完了すると、各ブランチの try サービスを呼び出すことによって最初のフェーズが始まります。
各ブランチがサービス呼び出しを完了しようとすると、最初のステージの結果に基づいて、TM に送信するか中止するかが通知されます。

言及すべきもう 1 つの点は、空の補償、再ハングなど、分散トランザクションに共通するいくつかの問題です。

一般的に言えば、企業は言語に絶するほどのエラーを回避するために、このシナリオを自ら処理する必要があります。

対応するサブトランザクションバリアソリューションは dtm で提供されます。核心はここにあります。

実際には、データベースの一意のインデックスメカニズムを使用することになります。もちろん、RM リソースごとに新しいテーブルを追加する必要があります。

前述のように、dtm の TM の役割は基本的に seata の TC に対応しますが、処理モードは異なります。

dtm の TM は、登録時に各ブランチによって保存されたアドレスに基づいて、各 RM 操作を http または rpc 経由で呼び出すかどうかを決定します。 RM へのリクエストは TM によって直接開始されます。

seata-go の実装では、TC は RM を直接呼び出すことには参加しません。

前回の記事で双方向ストリーム RPC インターフェース (BranchCommunicate) について説明したことを思い出してください。 TC はこのインターフェースを通じて対応するブランチ処理情報を RM マネージャーに渡します。

次に、RM マネージャーはトランザクションタイプに基づいて処理する対応するトランザクションマネージャーを選択し、最後に対応するトランザクションタイプマネージャーの BranchCommit メソッドを呼び出します。

以下は、TCC トランザクションタイプマネージャーのプロセスです。

対応するトランザクション RM マネージャーが各 RM リソースに通知し、処理する方法。

原理は前回の記事で述べた著者が実装したグローバルトランザクションプロキシモードです。基本的には Go リフレクションを使用して実装されます。興味があれば、ソースコードをダウンロードするか、著者によるグローバルトランザクションプロキシの実装の紹介[2]を読んでみてください。