Alibaba の調整システムの詳細な分析: 分散トランザクションの一貫性の課題!

導入

みなさんこんにちは、私はXiaomiです！今日は、Alibaba の面接の質問で話題になっている「分散トランザクションの一貫性」についてお話します。インターネット技術の急速な発展に伴い、分散システムは大手インターネット企業のアーキテクチャの基礎の 1 つになりました。しかし、分散システムでは、トランザクションの一貫性をどのように確保するかが常に難しい問題であり、多くの注目を集めてきました。今日は、私の理解と経験に基づいて、このトピックを詳しく分析します。

写真

分散トランザクションを避け、軽量ソリューションを採用する

今日のインターネット時代では、分散システムの適用は大企業にとって標準となっています。しかし、結果として生じる分散トランザクションの一貫性の問題は、開発者にとって大きな問題となっています。この問題に直面して、私たちの主な目的は、分散トランザクションの使用を可能な限り避け、代わりに軽量なソリューションを採用してデータの一貫性を確保することです。

分散トランザクションを避けるべき理由は何ですか?まず、分散トランザクションの実装は比較的複雑です。ノード間の通信や調整を考慮する必要があるだけでなく、さまざまな異常事態への対応も必要となり、システムの保守コストが増加します。第二に、分散トランザクションはシステムにさらなるパフォーマンスのオーバーヘッドをもたらし、システムのスループットと応答時間に大きな影響を与えます。最も重要なことは、分散トランザクションに問題が発生すると、システム全体の安定性に影響し、システムがクラッシュすることもあるということです。

では、分散トランザクションを回避するにはどうすればよいでしょうか?まず、単一プロセス内のトランザクション操作では、データベーストランザクションを使用して原子性と一貫性を確保できます。データベーストランザクションの実装は比較的シンプルでパフォーマンスも優れているため、リアルタイム要件が低いさまざまなビジネスシナリオの処理に適しています。次に、プロセス間通信のシナリオでは、非同期通信にメッセージキューを使用することを検討できます。メッセージキューは信頼性と安定性が高く、システム間の依存関係を効果的に分離できるため、システム間の結合が減り、システムの保守性とスケーラビリティが向上します。

分散システムでトランザクションの一貫性を実現するための主流のソリューション

分散システムでは、トランザクションの一貫性を確保することが重要です。この課題に対処するために、分散システムの各ノードでのデータ操作が一貫した状態に達することを保証することを目的とした、さまざまな主流のソリューションが業界で登場しました。

最終的な一貫性ソリューションは、メッセージキューに基づく信頼性の高いメッセージ配信メカニズムです。メッセージキューを通じて、システムはデータを非同期的に送信および処理し、最終的に一貫した状態に到達できます。このソリューションは、高いリアルタイムパフォーマンスを必要としないビジネスシナリオに適しており、システムのスループットと同時実行パフォーマンスを効果的に向上できます。
再試行と確認に基づくベストエフォート通知スキームは、再試行と確認のメカニズムに基づくベストエフォート通知スキームです。システムは通知の送信時に複数回再試行し、受信側で確認して、メッセージの確実な配信を保証します。このソリューションは、データの一貫性に対する要件が高いビジネスシナリオに適しており、メッセージの損失や重複処理の問題を効果的に軽減できます。

理論的には実現可能だが推奨されない解決策

分散システムでトランザクションの一貫性を扱う場合、理論的には実現可能だが推奨されない解決策がいくつかあります。これらのソリューションは理論上はデータの一貫性を保証できますが、実際のアプリケーションではさまざまな問題があり、インターネット業界の実際のシナリオには適していません。

まず、2 フェーズコミット (2PC) は、コーディネータと参加者間の相互作用を通じてトランザクションの一貫性を保証する、従来の分散トランザクションプロトコルです。しかし、2PC には単一障害点やパフォーマンスのボトルネックという問題があり、ネットワーク分割やノード障害が発生した場合にはトランザクションがブロックされ、システムの可用性と信頼性が低下します。

次に、3 フェーズコミット (3PC) は 2PC の改良版であり、タイムアウトメカニズムと状態同期メカニズムを導入することで、トランザクションのブロック時間を短縮し、単一点障害の影響を軽減します。ただし、3PC の実装は比較的複雑であり、ネットワークパーティションやノード障害などの状況ではトランザクションブロックの問題が依然として存在するため、高同時実行性、高可用性が求められるインターネットビジネスシナリオには適していません。

さらに、補正トランザクション (TCC) とロングトランザクション (SAGA) は、トランザクション実行の前後に補正操作を導入することでトランザクションの一貫性を保証する、補正メカニズムに基づく分散トランザクションソリューションです。ただし、TCC と SAGA の実装の複雑さは比較的高く、ビジネスロジックの要件も高いため、追加のリスクや不確実性が生じやすいため、すべてのビジネスシナリオに適しているわけではありません。

ローカルデータトランザクションの原則

ローカルデータベーストランザクションの原則には、UNDO ログ、REDO ログ、データベースロック、マルチバージョン同時実行制御 (MVCC) などの複数の主要コンポーネントが含まれており、これらが連携してトランザクションの原子性、一貫性、分離性、および永続性を保証します。

まず、トランザクションの実行が開始されると、データベースは現在のデータステータスを UNDO ログに記録します。これにより、トランザクション実行中に例外が発生した場合や、トランザクションをロールバックする必要がある場合でも、UNDO ログに基づいてデータベースをトランザクション実行開始前の状態に復元できます。これにより、トランザクションのアトミック性が保証されます。つまり、トランザクションは完全に実行されるか、完全にロールバックされ、部分的な実行は行われません。

次に、トランザクションが完了すると、データベースはトランザクションの実行後のデータの状態を REDO ログに記録します。これにより、データベースが異常終了した場合でも、システムはREDOログに基づいてデータベースをトランザクション完了後の状態に復元できるため、トランザクションの永続性が確保され、トランザクションの結果が失われることはありません。

さらに、データベースはデータベースロックメカニズムを通じてトランザクションの分離を保証します。トランザクションがデータベース内のデータを変更する必要がある場合、データベースは対応するデータ行またはデータテーブルをロックして、他のトランザクションによる変更やアクセスを防止し、同時操作によって発生するデータの不整合の問題を回避します。

さらに、マルチバージョン同時実行制御 (MVCC) は、データベースに複数のデータバージョンを保存することでトランザクションの分離を実現する、一般的に使用されるトランザクション分離メカニズムです。トランザクションの実行が開始されると、データベースはそのトランザクションのスナップショットを作成します。トランザクションはスナップショット内のデータのみを表示でき、他のトランザクションの影響を受けません。これにより、トランザクション間の干渉を回避し、データベースの同時実行パフォーマンスを向上させることができます。

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

分散システムにおけるトランザクション処理は、トランザクションの原子性、一貫性、分離性、および永続性を確保するために複数の側面を総合的に考慮する必要がある複雑かつ重要な問題です。分散システムでは、トランザクションの一貫性を実現することは非常に困難な作業であり、分散システム内のデータ操作が一貫した状態になるように、グローバルトランザクションコーディネーター、グローバルロック、ローカルデータベーストランザクションなどの複数のメカニズムを使用する必要があります。

まず、グローバルトランザクションコーディネーターは、分散システムにおけるトランザクションの一貫性を確保するためのコアコンポーネントの 1 つです。さまざまな参加ノード間でトランザクションの実行順序を調整し、システム全体でトランザクションの実行順序が一貫していることを保証する役割を担います。グローバルトランザクションコーディネータは、各参加ノードに指示を送信し、各ノードの実行結果を収集することで、トランザクションの一貫性を実現します。

第二に、グローバルロックは分散システムにおけるトランザクションの分離を保証する重要な手段です。グローバルロックを使用すると、複数のトランザクションが同時に同じデータを変更するのを防ぎ、データの読み取りと書き込みの競合を回避し、トランザクションの分離を確保できます。

さらに、ローカルデータベーストランザクションも、分散システムにおけるトランザクションの一貫性を確保する上で重要な役割を果たします。各参加ノードは、トランザクションを実行するときにローカルデータベーストランザクションを使用して、データの原子性、一貫性、分離性、および永続性を保証します。ローカルデータベーストランザクションは、UNDO ログ、REDO ログ、データベースロック、MVCC などのメカニズムを通じてトランザクションの一貫性を実現し、グローバルトランザクションコーディネーターおよびグローバルロックと連携して、分散システムにおけるトランザクションの一貫性を確保します。

推奨事項: 自社開発の補償/MQソリューション + 手動介入

当社では、分散システムにおけるトランザクションの一貫性の問題を解決するために、システムの安定性、パフォーマンス、保守性の確保を目的とした包括的なソリューションを採用しています。

まず、分散トランザクションへの過度の依存を避け、代わりに軽量なソリューションを採用してデータの一貫性を確保しました。単一プロセス内のトランザクション操作では、データベーストランザクションを最大限に活用して、原子性と一貫性を確保します。ローカルデータベーストランザクションメカニズムを使用すると、分散トランザクションによって生じる追加のオーバーヘッドと複雑さを回避しながら、単一のサービス内のデータ操作が一貫した状態になることを保証できます。

次に、プロセス間通信シナリオでは、非同期通信にメッセージキューを使用します。メッセージキューを使用すると、システムのスケーラビリティと保守性を確保しながら、異なるサービス間のデータ転送の信頼性と効率が向上します。メッセージキューの導入により、システム間の結合が減少し、システムの全体的なパフォーマンスと柔軟性が向上します。

実際のアプリケーションでは、これら 2 つのメカニズムを効果的に調整しています。複数のサービスが関与する業務オペレーションについては、複数の独立したアトミックオペレーションに分割し、メッセージキューを使用して対応するサービスにデータを送信することで、分散トランザクションの分離と非同期化を実現します。ローカルデータベーストランザクションメカニズムとメッセージキューの連携により、システムのデータ一貫性が確保されるだけでなく、システムのパフォーマンスと保守性が向上し、ユーザーに優れたサービスエクスペリエンスが提供されます。

さらに、システム調整中の一貫性の問題を解決するために、独自に開発した補正/MQ ソリューションと手動介入も採用しました。このソリューションは、システムの安定性を保証するだけでなく、パフォーマンスの低下を最小限に抑え、システムの制御性と保守性を向上させます。これにより、さまざまなビジネスシナリオにおける分散トランザクションの問題に柔軟に対応し、システムの安定した運用を確保できます。

非推奨: Seata ATモード

Seata AT モードは、Alibaba のオープンソース分散トランザクションソリューションです。ただし、実際のアプリケーションでは、Seata AT モードを使用するとパフォーマンスが低下する可能性があります。統計によると、Seata AT モードを使用すると平均パフォーマンスが 35% 以上低下し、これは無視できない課題です。

パフォーマンスの低下は主に、Seata AT モードで採用されている 2PC (2 フェーズコミット) プロトコルが原因です。分散トランザクションでは、2PC は複数の参加ノードのトランザクション操作を調整する必要があります。これには、事前コミットと最終コミットの 2 つの段階が含まれます。この調整メカニズムにより、ネットワーク通信のオーバーヘッドと待機時間が増加し、トランザクション実行の効率が低下します。

さらに、Seata AT モードでは、グローバルトランザクションコーディネーターと参加ノード間の頻繁な通信と同期が必要になるため、これによってもシステム負荷と応答時間が増加します。特に、同時実行性が高く、データ量が多いシナリオでは、このパフォーマンスの低下はさらに顕著になり、システムのパフォーマンスがビジネスニーズを満たせなくなる可能性があります。

ただし、Seata AT モードではパフォーマンスが低下するという問題があるものの、特定のシナリオでは依然として実行可能なオプションであることは言及する価値があります。たとえば、データの一貫性に対する要件は高いが同時実行性はそれほど必要ではないビジネスシナリオの場合、Seata AT モードを使用するとトランザクションの一貫性を確保でき、ある程度のパフォーマンスの低下は許容できます。

非推奨: RocketMQ トランザクションメッセージ

RocketMQ トランザクションメッセージングは強力な分散メッセージングソリューションですが、特に強力な同期を伴うリンクの処理など、一部のビジネスシナリオには適用できない場合があります。

メッセージの順序を保証する必要があるビジネスシナリオや非常にリアルタイムなビジネスシナリオなど、強力な同期を伴うリンクの処理には、RocketMQ トランザクションメッセージは適さない可能性があります。 RocketMQ トランザクションメッセージ処理メカニズムでは、メッセージをメッセージキューに送信する前にローカルトランザクションが完了するのを待つ必要があるため、メッセージ送信に遅延や不確実性が生じます。同期が強力なビジネスシナリオでは、遅延や不確実性がビジネスプロセスに悪影響を及ぼし、一連の問題を引き起こす可能性もあります。

さらに、メッセージの順序を保証する必要があるビジネスシナリオでは、RocketMQ トランザクションメッセージにもいくつかの制限がある場合があります。 RocketMQ トランザクションメッセージは、ローカルトランザクションを通じてメッセージの順序とメッセージが送信される順序を保証できますが、実際のアプリケーションでは、ネットワークの遅延やノード障害などの要因により、メッセージの順序が乱れ、ビジネスロジックにエラーや不整合が生じる可能性があります。

ただし、非同期性が強く、メッセージシーケンスにあまり依存しない一部のビジネスシナリオでは、RocketMQ トランザクションメッセージングは依然として非常に効果的な選択肢となります。たとえば、データの最終的な一貫性を保証する必要があるものの、メッセージ送信のリアルタイム性とシーケンシャル性に対する要件は高くないビジネスシナリオの場合、RocketMQ トランザクションメッセージはニーズを十分に満たし、トランザクションステータスとコールバックメカニズムを通じてメッセージの信頼性の高い送信を保証し、システムの安定性と信頼性を確保します。

下流 MQ の消費成功問題

メッセージキューシステムでは、メッセージが下流のコンシューマーによって正常に消費されることを保証することが重要です。メッセージが正常に消費されない場合は、データの損失、ビジネスロジックエラー、システムの不整合などの重大な結果につながる可能性があります。したがって、下流の MQ コンシューマーがメッセージを正常に消費できる必要があることを強調します。メッセージの消費が失敗したり、異常な状況が発生した場合は、システムの安定した動作とデータの一貫性を確保するために迅速に介入する必要があります。

メッセージが正常に消費されることを保証するには、まずメッセージの送信者と受信者の間で適切な通信メカニズムとプロトコルを確立する必要があります。メッセージ送信者は、メッセージをタイムリーにメッセージキューに送信し、メッセージ送信の信頼性を確保できる必要があります。メッセージがタイムリーかつ正確に消費されることを保証するために、メッセージ受信者は高い信頼性と高い同時処理能力を備えている必要があります。

メッセージのコンシューマー側では、メッセージが繰り返し消費されてもシステムに悪影響を与えないように、べき等性を実装する必要があります。べき等性を実現することで、メッセージの繰り返し消費によって発生するデータエラーやビジネスロジックの異常を効果的に回避し、システムのデータの一貫性と安定性を確保できます。

さらに、メッセージの消費が失敗したり例外が発生したりした場合は、すぐに介入する必要があります。これを処理する一般的な方法は、失敗した消費メッセージを手動処理キューに転送し、専門家が分析および処理することです。手動介入により、メッセージ消費障害の原因を迅速に発見して解決し、システムの正常な動作とデータの一貫性を確保できます。

冪等性の実現

メッセージキューシステムでは、べき等性を実現することが重要です。べき等性とは、メッセージが何回消費されてもシステムの状態は変更されず、システムのデータの一貫性と安定性が保証されることを意味します。したがって、重複したメッセージの消費から生じる可能性のあるリスクと課題に対処するには、必ずべき等性を実現することが必要であることを強調します。

べき等性を実現するための鍵は、消費者のビジネスロジックを設計することにあります。まず、コンシューマーの処理ロジックがべき等であること、つまり同じメッセージが複数回消費されてもシステムの状態が一貫していることを確認する必要があります。これには通常、異なるメッセージを区別し、この情報に基づいてメッセージが処理されたかどうかを判断するために、コンシューマーのビジネスロジックに一意の識別子やバージョン番号などの情報を追加する必要があります。

第二に、消費者のビジネスロジックに冪等性チェックと保護メカニズムを実装する必要があります。これには、重複した消費が影響を与えないようにするための、コンシューマーの処理ロジックの冪等性チェックが含まれます。同時に、重複したデータの挿入や更新を防ぐために、データベース操作で一意のインデックスや楽観的ロックを使用するなど、消費者の処理ロジックに冪等性の保護策を追加する必要があります。

さらに、メッセージの一意の識別子やメッセージ ID などの情報を使用して、メッセージの重複排除と冪等性を実現することもできます。処理されたメッセージの ID を記録することで、コンシューマーが冪等性チェックを実行するときにメッセージが処理されたかどうかをすばやく判断でき、繰り返しの消費や繰り返しの処理を回避できます。