分散マイクロサービス アーキテクチャ アプリケーションで最終的な一貫性を実現するにはどうすればよいですか?

分散システムでは、強力な一貫性を実現するのは簡単ではありません。 2PC ステージと 3PC ステージがコミットされたとしても、絶対的な強力な一貫性は保証されません。

また、不整合の可能性が極めて低いために、システム全体のパフォーマンスが低下したり、スケーラビリティが影響を受けたり、アーキテクチャが極端に複雑になったりすることも許されません。したがって、2PC/3PC 送信の大規模なアプリケーションがない場合、結果整合性はより優れたソリューションであり、業界で広く使用されています。

1. 再試行メカニズム

下の図に示すように、サービス コンシューマーはサービス A とサービス B を同時に呼び出します。サービス A が正常に呼び出されると、サービス B が認識されます。最終的な一貫性を確保するための最も簡単な方法は再試行することです。

再試行するときは、リソース枯渇につながる長時間の待機やフリーズを回避するために、サービス コンシューマーのタイムアウトを必ず設定してください。

コンシューマーが再試行する場合、次の点に注意する必要があります。

• タイムアウト期間;
• 再試行回数。
• 再試行の間隔。
• 再試行間隔の減衰率。

具体的な実装の詳細については、「Spring-tryer に基づくエレガントな再試行ソリューション」を参照してください。

2. ローカルログ

ログをローカルに記録し、分散監視システムまたはその他のバックエンド システムに収集することで、定期的な検査ツールを開始します。実際の状況に応じて、手動処理を選択できます。

ログ形式: TranID-AB-Detail

• TransID は、ランダムなシーケンス番号を生成できるトランザクション ID です。
• 詳細はデータの詳細な内容です。
• A への呼び出しが成功した場合は、A の成功を記録します。
• B の呼び出しが失敗した場合、または失敗や記録がないなどの場合、つまりログに B の成功がない場合は、再度 B を呼び出します。
• ログは定期的に確認および処理できます。

以下に示すように、識別ログの設計図を集めます。

3. 信頼性の高いメッセージモード

実際のビジネスシナリオでは失敗する確率が比較的低いことを考慮すると、次のような解決策が考えられます。

サービス コンシューマーはサービス B の呼び出しに失敗し、最初に再試行します。再試行が一定回数失敗した場合、メッセージは直接メッセージ キューに送信され、非同期処理に変換されます。

非同期処理には、Kafka、RocketMQ、その他のオープンソース分散メッセージング システムなどの強力な分散機能を備えた MQ を使用できます。

• サービス B は専用のエラー処理コンポーネントを統合して、MQ から補正メッセージを継続的に収集できます。
• または、他のサービス コンポーネントの例外を含む MQ 補正メッセージを独立して処理するための独立したエラー処理コンポーネントを作成します。

このソリューションには、メッセージが失われるリスクもあります。つまり、メッセージが送信される前にサービス コンシューマーがクラッシュするリスクがありますが、これは発生確率の低いイベントです。

次の図に示すように、別の解決策として信頼性の高いメッセージング モードがあります。サービス コンシューマーは、RocketMQ、Kafka などのメッセージ キュー ブローカーにメッセージを送信します。メッセージは、サービス A とサービス B によって消費されます。

MQ は分散 MQ を使用でき、永続化できるため、メッセージが失われないことを保証でき、MQ は信頼できるものと見なされます。

信頼性の高いメッセージング モードの利点:

• スループットの向上
• シナリオによっては、応答時間が短縮されます。

問題点:

• 時間ウィンドウに一貫性がありません (ビジネス データは MQ には入りますが DB には入りません。そのため、シナリオによってはビジネス データを読み取ることができません)。
• アーキテクチャの複雑さが増す。
• コンシューマー (サービス A/B) は冪等性を保証する必要があります。

上記の矛盾した時間ウィンドウの問題は、さらに最適化することができます。

• 事業をコア事業とサブ事業に分ける
• コアビジネスサービス - 直接通話。
• 依存ビジネス サービス - MQ からのメッセージを消費します。

注文サービス（コアサービス）を直接呼び出して、ビジネス注文データを DB に保存します。同時に、MQ にメッセージを送信します。

サービス コンシューマー (注文の作成) が MQ にメッセージを送信する前に失敗する可能性があることを考慮すると、分散トランザクションの処理は面倒でパフォーマンスに影響するため、注文サービスの呼び出しとメッセージの送信は 1 つのトランザクションで実行する必要があります。

したがって、注文テーブルと同じデータベースにイベント テーブルという別のテーブルが作成されます。トランザクション保護を追加して、分散トランザクションを単一のデータベース トランザクションに変換できます。

全体のプロセスは次のとおりです。

（1）注文を作成する - ビジネス注文データを永続化し、イベントテーブルにイベントレコードを挿入します。一貫性を確保するために、これは 1 つのトランザクションで実行されることに注意してください。失敗した場合は、ビジネス サービスのロールバックを心配する必要はありません。成功した場合は、ビジネス サービスは継続されます。

（２）メッセージの送信 - 注文メッセージをメッセージキューに送信します。

• メッセージの送信に失敗した場合は、再試行が実行されます。再試行が成功する前にメッセージが失敗した場合、補正サービスはメッセージを再送信します (低確率のイベント)。
• 補正サービスは、イベント テーブルを継続的にポーリングして異常なイベントを検出し、補正メッセージを送信します。成功した場合は無視されます。
• メッセージが正常に送信された場合、または補正サービスがメッセージを正常に送信する場合は、イベント テーブル内のイベント情報レコードを削除すること (論理削除) を検討できます。

（3）メッセージの消費 - 他の従属ビジネスサービスはMQ内の注文メッセージを消費し、独自のビジネスロジックを処理できます。

上記の設計では、注目すべき点が 3 つあります。

（１）注文サービス（コアビジネス）を直接呼び出すことで、ビジネス注文データができるだけ早く配信され、時間枠の不一致の問題を回避し、読み取り後の書き込みの一貫性が確保されます。

（２）注文業務は、メッセージをMQに直接送信することでリアルタイム性を高めます。補償サービスは異常事態の場合にのみ利用されます。リアルタイム要件が高くない場合は、メッセージを直接送信するロジックを削除することも検討できます。

（３）追加のイベントテーブルを導入する目的は、分散トランザクションを単一のデータベーストランザクションに変換することであり、これによっても、ある程度、データベースへの負荷が増加します。