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

[[439474]]

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

導入

気がつけば1ヶ月も更新していませんでした。一度怠け者になると、ますます怠け者になるだけだ。

最近、分散トランザクションに興味を持ち、いくつかの記事や論文を読みました。この記事は主に私が見た 2 つのプロジェクトを紹介するもので、理論的な知識は含まれていません。

Alibaba の Seata のオープンソースバージョン。主に seata-golang の Go 実装 (Java バージョンの背後) に注目しています。
そして、しばらく前に多くの公開アカウントが投稿した DTM。

シータの紹介

Seata は、Alibaba が提供するオープンソースの分散トランザクションサービスです。現在、AT、TCC、SAGA、XA トランザクションモードをユーザーに提供しており、全体として 2 フェーズコミットプロトコルを採用しています。 seata-golang の Go バージョンは現在、MySQL の AT モードと TCC モードのみを実装しているようで、作者は現在ほとんど更新していません。

Seata にはいくつかの主要な役割があります。

TC (トランザクションコーディネーター) - トランザクションコーディネーター。 (グローバルおよびブランチトランザクションの状態を維持し、グローバルトランザクションのコミットまたはロールバックを実行します)
TM (トランザクションマネージャー) - トランザクションマネージャー。 (グローバルトランザクションのスコープを定義します。グローバルトランザクションを開始し、グローバルトランザクションをコミットまたはロールバックします。)
RM (リソースマネージャー) - リソースマネージャー。 (ブランチトランザクション処理のリソースを管理し、TC と通信してブランチトランザクションを登録し、ブランチトランザクションのステータスを報告し、ブランチトランザクションをコミットまたはロールバックします)

もちろん、これだけでは分かりにくいかもしれませんので、公式サイトから画像を使って説明しましょう。

上の図からわかるように、これら 3 つの役割の責任は次のとおりです。

グローバルおよびブランチトランザクションの状態を維持するには、ストレージが必要です。
分散トランザクションが完了すると、各 RM にコミットするかロールバックするかを通知する必要があります。

TC に分散トランザクションを開始し、グローバルに一意の分散 ID を取得するよう要求します。
最初のフェーズで分散トランザクションに参加している各 RM からのフィードバックに基づいて、2 番目のフェーズで TC に分散トランザクションのコミットまたはロールバックを要求するかどうかを決定します (ほとんどのシナリオでは、最初のフェーズでいずれかの RM に障害が発生すると、分散トランザクションは失敗します)。

簡単に言えば、分散トランザクションに関係するさまざまなサービス（従来の注文シナリオに関係する注文サービス、在庫サービス、マーケティングサービスなど）を管理します。

ps: 個人的には、ここでの RM はマイクロサービスの中間処理層に少し似ていると感じています (専門用語では、これをフロントエンドの bff->backend と呼びます)。

1 段階の準備動作 (アクティブ): 各 RM はカスタマイズされた準備ロジックを呼び出します。
第 2 段階のコミット動作 (パッシブトリガー): この分散トランザクションの第 1 段階ですべての RM が成功した場合、TC は自身の状態変更を処理した後、各 RM のカスタムコミットロジックを呼び出します。（第1フェーズのすべてのRMは成功しました）
第 2 段階のロールバック動作 (パッシブトリガー): この分散トランザクションの第 1 段階でいずれかの RM が失敗した場合、TC は独自の状態変更を処理した後、各 RM のカスタマイズされたロールバックロジックを呼び出します。 (どのRMも最初の段階で失敗します)

大丈夫。以下に、seata-golang の実装の詳細を示します。 seata-golang の基盤となるレイヤーでは、通信に gRPC を使用します。

シータ-ゴラン

まず、RM 構造を見てみましょう。

マネージャーに関しては、サポートされている主要なトランザクションモードの実装 (TCC、XA など) を保存し、各モードではこのインターフェイスを実装するだけで済みます。

TC の部分構造を見てみましょう (いくつかのフィールドを削除します)。

TC は現在、データストレージとして MySQL と pgsql をサポートしています。つまり、SessionManager インターフェイスを実装し、それを SessionHolder のマネージャーに挿入するだけです。

これら 2 つの基本構造を紹介した後、それらの関係について上で述べたことを覚えていますか?

第 2 段階では、TC は現在のトランザクションステータスに基づいて、コミットするかロールバックするかを RM に通知します。

ResourceManagerを初期化するとき、

最後に TC の grpc インターフェース branchCommunicate が呼び出されることがわかります。

サーバーに対応しています。

gRPC には 4 つの基本的な通信モードがあることがわかっています。

単項RPC
サーバーストリーミングRPC
クライアントストリーミングRPC
双方向ストリーミング RPC

ストリーミング形式を希望するのも非常に簡単です。 proto メソッド定義内の対応する request|response パラメータの前にストリームタグを追加するだけで、このインターフェイスがストリーミングされます。ストリームの種類は、ストリームを追加する場所によって異なります。リクエストとレスポンスの両方を追加すると、双方向ストリームになります。

クライアントとサーバーは両方とも、stream.Send を介してリクエストを送信し、stream.Recv を介してデータを受信できます。

RMがBranchCommunicateを呼び出すと、

最後に、ブランチトランザクションが処理され、manager.BranchCommit が呼び出されます。

同様に、TCがRMによって呼び出されると、

コミットまたはロールバックを通知するために RM に送信されるデータはどこから来るのでしょうか?

TCがRMにブランチをコミットするように通知したい場合、

最後はTMですが、これは理解するのが難しくありません。

実際、seat-golang については言及する価値のあることが他にもあります。

たとえば、go リフレクションによって実装された動的プロキシ関数を書くのは面倒です (まったく不要だと思いますが)。

この記事はもう一回書くと長くなるので、dtmについてはこれ以上書きません。ご興味がございましたら、メッセージを残していただければ、DTM を作成するかどうか検討させていただきます。

参照する

https://seata.io/zh-cn/docs/overview/what-is-seata.html