オープンソースの分散トランザクションミドルウェアFescarについて、開発者が懸念する13の問題点をまとめました

[[255813]]

© 立石幹人

オープンソースの分散トランザクションミドルウェア Fescar の v0.1 バージョンが 1 月 10 日にリリースされて以来、開発者から大きな注目を集めています (コミュニティで議論された watch249、star3005、fork649、issue58、1 月 17 日 14:00 時点のデータ統計)。世界は長い間、分散型取引に悩まされてきたことがわかります。

そこで、コミュニティ（Github）やコミュニティ内で皆さんが懸念している中核的な課題を収集し、以下のようにまとめ、回答をさせていただきました。

Q1: Fescarの開発の歴史を教えてください。 Fescar と Alibaba Cloud Global Transaction Service GTS との関係は何ですか?

A1: アリババは中国でいち早くアプリケーションを分散型（マイクロサービス）アプリケーションに変換した企業の 1 つであるため、マイクロサービス アーキテクチャにおける分散トランザクションの問題に非常に早い段階で遭遇しました。

• 2014

Alibaba のミドルウェア チームは、グループ内のアプリケーションに分散トランザクション サービスを提供するために、TXC (Taobao Transaction Constructor) をリリースしました。

• 2016

製品変革後、TXC は Alibaba Cloud 上で GTS (Global Transaction Service) としてリリースされ、当時業界で唯一のクラウドベースの分散トランザクション製品となりました。これは、Alibaba Cloud パブリック クラウドまたはプライベート クラウド ソリューションの形で多くの外部顧客に提供されました。

• 2019

TXC と GTS の技術的蓄積に基づいて、Alibaba のミドルウェア チームはオープン ソース プロジェクト Fescar (Fast & EaS​​y Commit And Rollback、FESCAR) を立ち上げ、コミュニティと協力してこの分散トランザクション ソリューションを構築しました。

TXC/GTS/Fescar は同じ起源を持ち、マイクロサービス アーキテクチャにおける分散トランザクションの問題に対する独自のソリューションを提供します。

Q2: Fescar に適用可能なシナリオは何ですか?

A2: Fescar のビジョンは、分散トランザクションの使用を、現在のローカル トランザクションの使用と同じくらいシンプルかつ効率的にすることです。最終的な目標は、すべての分散トランザクション シナリオに適用できるようにすることです。現在、コア AT モードは、ネイティブ ACID トランザクション サポート上に構築されたリレーショナル データベースに適しています。非リレーショナル データベース リソースの管理は、MT モードを通じてサポートされます。 AT モードは MT モードと完全に互換性があるため、両方のタイプのリソースを同じ分散トランザクションで管理できます。

Q3: 他にもオープンソースの分散トランザクション ソリューションがすでにいくつか存在します。 Fescar とそれらの違いは何ですか? Fescar と JTA の分散トランザクションのサポートの違いは何ですか?

A3: 既存の分散トランザクション ソリューションは、ビジネスへの侵入の度合いに応じて、非侵入型と侵入型の 2 つのカテゴリに分類されます。

• 非侵入型ビジネスソリューション

既存の主流の分散トランザクション ソリューションの中で、ビジネスに支障をきたさないのは XA ベースのソリューションだけです (注: 質問で言及されている JTA は、XA ソリューションの Java バージョンです)。ただし、XA ソリューションの適用には 3 つの問題があります。

1. データベースは XA をサポートする必要があります。 XA をサポートしていない (または MySQL 5.7 より前のバージョンのように XA のサポートが不十分な) データベースに遭遇した場合、XA は使用できません。

2. プロトコル自体の制約により、トランザクション リソース (データ レコード、データベース接続) のロック期間が長くなります。ビジネスの観点から見ると、トランザクション リソースの管理者はデータベース自体であり、アプリケーション層が介入できないため、長期間のリソース ロックは多くの場合不要です。その結果、XA ベースのアプリケーションはパフォーマンスが低下し、最適化が困難になることがよくあります。

3. 実装されている XA ベースの分散ソリューションはすべて、マイクロサービス アーキテクチャには適していない重量級のアプリケーション サーバー (Tuxedo/WebLogic/WebSphere など) に依存しています。

• ビジネスに介入する計画

実際、当初は XA が分散トランザクションの唯一のソリューションでした。 XA は完全ですが、実際にはさまざまな理由 (上記の 3 つの点を含みますが、これらに限定されません) により、XA を放棄して、ビジネス レベルから分散トランザクションの問題を解決する必要があることがよくあります。例えば：

• 信頼性の高いメッセージに基づく最終的な一貫性ソリューション
• TCC
• 佐賀

すべてこのカテゴリに属します。これらの計画の具体的な仕組みについては、インターネット上でこのトピックについて議論している記事が多数あるため、ここでは詳しく説明しません。つまり、これらのソリューションでは、アプリケーションのビジネス レベルでの設計において、分散トランザクションの技術的な制約を考慮する必要があります。通常、各サービスは、順方向および逆方向の冪等インターフェースを実装するように設計する必要があります。このような設計上の制約により、多くの場合、研究開発費と保守費が高額になります。

侵入ビジネス向けの分散トランザクションソリューションは、多数の実践によって検証されており、問題を効果的に解決でき、さまざまな業界のビジネスアプリケーションシステムで重要な役割を果たしていることは否定できません。しかし、出発点に戻って考えてみると、これらの解決策が採用されたのは、実は無力感からだったのです。

質問に戻ります:

メッセージベースの結果整合性、TCC、Saga などのビジネス ロジック侵入ソリューションとは異なり、Fescar はビジネスに侵入しないように設計されており、分散トランザクションの特定のシナリオに応じて、ビジネス レイヤーで 2 セット (または複数セット) の順方向ビジネス ロジックと逆方向ビジネス ロジックを設計する必要がありません。この点については違いについては詳しく説明しません。

XA との違いは、XA とは異なる 2 フェーズ プロトコルが、ビジネスに支障をきたすことなく優れたパフォーマンスを確保し、基盤となるデータベース プロトコルのサポートの必要性を回避するように設計されていることです。これは軽量な XA メカニズムとみなすことができます。具体的な違いは次のとおりです。

• アーキテクチャレベル

XA ソリューションの RM は、実際にはデータベース層にあります。 RM は本質的にはデータベースそのものです (アプリケーションで使用するために XA 対応ドライバーが提供されます)。

Fescar の RM は、セカンドパーティ パッケージの形式でミドルウェア レイヤーとしてアプリケーション側に展開されます。これは、データベース自体のプロトコル サポートに依存せず、もちろんデータベースが XA プロトコルをサポートする必要もありません。これはマイクロサービス アーキテクチャにとって非常に重要です。アプリケーション層では、ローカル トランザクションと分散トランザクションに 2 つの異なるデータベース ドライバーを適応させる必要がありません。

この設計により、分散トランザクション ソリューションにおけるデータベース プロトコルのサポートが不要になります。

• 2フェーズコミット

まず、XA の 2PC プロセスを見てみましょう。

Phase2 の解決がコミットかロールバックかに関係なく、トランザクション リソースのロックは Phase2 が完了するまで保持する必要があります。

Fescar の 2PC プロセスを見てみましょう。

ブランチ トランザクション内のデータのローカル ロックは、ローカル トランザクションによって管理され、ブランチ トランザクション フェーズ 1 が終了すると解除されます。

同時に、ローカル トランザクションが終了すると、接続が解放されます。

ブランチトランザクション内のデータのグローバルロックは、トランザクションコーディネーター側で管理されます。 Phase2 のグローバル コミットが解決されると、グローバル ロックはすぐに解除できます。グローバル ロールバックが決定された場合にのみ、ブランチのフェーズ 2 が終了するまでグローバル ロックが保持されます。

この設計により、ブランチ トランザクションがリソース (データと接続) をロックする時間が大幅に短縮され、全体的な同時実行性とスループットを向上させる基礎が提供されます。

Q4: Fescar はどのバージョンの Dubbo をサポートしていますか?

A4: すべてのバージョン。

Q5: Fescar は Spring Cloud をサポートしていますか?

A5: Fescar とマイクロサービス フレームワーク間のインターフェースは、トランザクションの一意の識別子 XID (文字列) をマイクロサービス フレームワークのサービス呼び出しメカニズムを通じて透過的に送信し、Fescar API を通じてアプリケーションのスレッド コンテキストにバインド (またはアンバインド) する必要があることです。 (仕組みについては、Dubbo サポートの組み込み実装 com.alibaba.fescar.dubbo.TransactionPropagationFilter を参照してください) したがって、本質的には、Spring Cloud がサポートされているかどうかではなく、Spring Cloud で選択されたサービス呼び出しの仕組みをどのようにサポートするかが問題となります。現在、Spring Cloud Alibaba の同僚と協力して、Spring Cloud バージョン v0.5.x (またはそれ以前) のデフォルト サポートをリリースする準備をしています。同時に、コミュニティの友人が参加して、Spring Cloud を含むさまざまなマイクロサービス フレームワークのサポートに貢献することを歓迎します。

Q6: Fescar はローカルのクロスデータベースの複数のデータソースをサポートしていますか?リレーショナル データベースに加えて、NoSQL データベースもサポートされていますか?

A6: ローカルの複数のデータ ソースもサポートされています。 Fescar アーキテクチャでは、同じサービス内の複数のデータ ソースと、サービス間の複数のデータ ソースの間に本質的な違いはありません。 AT モードは現在、リレーショナル データベース (ACID トランザクション サポートがある) のサポートに制限されています。今後リリースされる MT モードでは、NoSQL などのローカル トランザクション サポートがないリソースもサポートできます。

Q7: Fescar は現在 AT モードのソースを公開しており、MT モードはまだサポートされていません。いつオープンソース化されるのでしょうか?

A7: 現在のバージョン 0.1.0 では、Fescar のコア AT モードの最小セットのみがリリースされています。一方では、オープンソースの計画とアーキテクチャ再構築の進捗と一致しています。一方、アリババに完全に支配され、ソリューション全体をオープンソース化して誰もが使用できるようにするのではなく、最小セットバージョンを通じて、ユーザーと開発者コミュニティが私たちのコアな設計アイデアをより簡単に理解し、より多くの人が構築に参加しやすくなることを願っています。私たちは、分散型トランザクションにおけるアリババの技術的蓄積を、Fescar プロジェクトを通じてコミュニティに惜しみなく貢献し、すべての機能は計画とコミュニティのフィードバックに従って徐々にオープンソース化されます。当初の計画によれば、MT はバージョン 0.5.x でリリースされる予定です。

Q8: Fescar はいつ HA クラスターを提供しますか?シングルノードサーバーのボトルネックに対処するにはどうすればよいでしょうか?

A8: 予備計画によれば、スタンドアロン展開の単一点問題を解決するために、HA クラスターがバージョン 0.5.x でリリースされる予定です。

Q9: Fescar は、ネットワーク中断、ネットワーク障害、ノードダウンタイム、タイムアウトなどによる異常に対して、対応する補償措置を提供しますか?

A9: これらの例外を処理することは、分散トランザクション ソリューションの基本要件です。 Fescar は、さまざまな例外シナリオを処理するための完全なソリューション セットも提供します。この点に関する具体的なメカニズムは、HA Cluster バージョンがリリースされたときに総合的に分析され、紹介される予定です。

Q10: Fescar フレームワークで分散トランザクションを監視するにはどうすればよいでしょうか?

A10: 監視は非常に重要な部分です。 TXC および GTS モニタリングでは、Alibaba 内のインフラストラクチャ サポートが大量に使用されます。オープンソース版には、既成の監視ソリューションはありません。一般的に、監視は 2 つの側面に基づいています。1 つはログです。ログの収集と処理を通じて、完全なトランザクション チェーンを形成できます。これらのデータは、ビジネス レベルの分析とチューニングにとって重要な参照資料となります。一方、Fescar は、ランタイム トランザクションを管理するための一連の管理 API を提供します。今後は、これら 2 つの側面のデータ形式、展開形式、インターフェースを整理し、コミュニティと協力して監視のこの重要な側面を構築したいと考えています。

Q11: Fescar のロードマップはありますか?

A11: 最新のロードマップは次のとおりです。

バージョン0.1.0

• マイクロサービスフレームワークのサポート: Dubbo
• データベースサポート: MySQL
• Spring AOP に基づくアノテーション
• トランザクションコーディネーター: スタンドアロンバージョン

v0.5.x

• マイクロサービスフレームワークのサポート: Spring Cloud
• MTモード
• TCCモードトランザクション適応をサポート
• 動的構成とサービス検出
• トランザクションコーディネーター: 高可用性クラスタエディション

バージョン0.8.x

• メトリクス
• コンソール: 監視/デプロイメント/アップグレード/スケーリング

バージョン1.0.0

• 一般提供: 実稼働環境に適用可能

バージョン1.5.x

• データベースサポート: Oracle/PostgreSQL/OceanBase
• Spring AOPに依存しないアノテーション
• ホットスポットデータの最適化された処理メカニズム
• RocketMQトランザクションメッセージはグローバルトランザクション管理に含まれる
• グローバルトランザクション管理を組み込むためのNoSQL適応メカニズム
• HBaseのサポート
• Redisのサポート

バージョン2.0.0

• XA のサポート

もちろん、プロジェクトの反復と進化のプロセスにおいて、私たちが最も重視するのはコミュニティの声であり、ロードマップはコミュニティと十分にコミュニケーションされ、タイムリーに調整されます。

Q12: Fescar公式サイトはいつ公開されますか？

A12: Fescarの公式ドメイン名が登録されました。公式ウェブサイトは、静的オープンソースサイト構築ツール Docsite を使用して構築されます。ロゴはデザインされており、近日中に発表される予定です。

Q13: Fescar コミュニティに参加して貢献するにはどうすればよいですか?もう試してみたくてたまりません。

A13: 私たちは、以下のようなさまざまな形で、皆様がプロジェクトの構築に参加することを歓迎します。

• 建築デザイン
• モジュラー設計
• コードの実装
• バグ修正
• デモ例
• ドキュメント、ウェブサイト、翻訳

具体的な参加方法については、当プロジェクトのCONTRIBUTINGガイドラインを参照するか、@[email protected] までお問い合わせください。実際のところ、寄付の形態に制限はありません。バグ報告、改善提案、あるいは問題の相談など、開発者が提起するすべての問題は、プロジェクトに対する注目と支援を意味します。 Fescar プロジェクトとコミュニティが健全に成長し、分散トランザクションの分野で優れたソリューションになることを願っています。

この記事の著者: コミュニティ内で sharajava というニックネームを持つ Xuan Yu は、Fescar オープンソース プロジェクトの創始者であり、Alibaba のミドルウェアの TXC/GTS R&D チームの責任者です。彼は長年にわたりWebLogicコアの研究開発に従事し、ミドルウェアに重点を置き、分散トランザクションの分野で豊富な技術実践を持っています。