ビジネスシナリオの紹介
単一システム注文
単一のeコマースシステムでは、注文操作全体が同じメソッドで完了し、商品に対応するテーブルと注文に対応するテーブルがデータベースの原子性（Atomicity）に従って同じデータベースにあるため、ユーザーは正常に注文します。 、一貫性、分離または永続的に。注文サービスが成功すると、在庫が差し引かれ、注文操作を生成するためのデータが同時に有効になります。プロセスは次のとおりです。
分散システムの注文
分散システムでは、注文プロセスがマイクロサービス化され、注文プロセスは注文サービスと商品サービスに分割されます。このとき、データベースも分解され、対応する注文データベースと商品データベースに分割されます。上記のプロセスの同じトランザクションのメソッドに従って、対応するマイクロサービスに直接置き換えると、フローチャートは次のようになります。
RPCまたはHTTPリクエストを使用して、注文サービスで商品サービスおよび注文サービスを呼び出す場合、異常なネットワークまたはサーバーのダウンタイムにより、商品のデータが注文データベースのデータと一致しない場合があります。注文サービスがある可能性があります。異常なデータのロールバックにより、商品が呼び出されたときに注文データベースにデータが生成されず、商品サービス処理が成功しました。商品データベースの在庫控除が成功しました。ネットワーク異常またはサーバーのダウンタイムの理由の例は次のとおりです。
分散トランザクション
2フェーズデータベース送信
上記のようにマイクロサービスに分割した後のデータの不整合の問題を解決するにはどうすればよいですか？このとき、分散トランザクションを導入する必要があります。在庫の控除と注文の生成が分散システムで同時に有効になる場合は、データベースの2段階の送信方法によって実現できます。CAP理論によると（詳細については、CAP理論と適用可能なシナリオの詳細な理解を参照してください）、2PCはCPモードに属します。
データベース分散トランザクションを理解する学生は、データベースでサポートされる2PCがXAトランザクションとも呼ばれることを知っている必要があります。その中で、XAは2段階の提出契約であり、契約は次の2つの段階に分かれています。
- 第1段階：トランザクションコーディネーターは、トランザクションに関与する各データベースに、この操作を事前コミット（事前コミット）して、コミットできるかどうかを反映するように要求します。
- 第2段階：トランザクションコーディネーターは、各データベースにデータを送信するよう要求します。
その中で、いずれかのデータベースがこの送信を拒否した場合、すべてのデータベース操作データがロールバックされます。この方法はパフォーマンスに重大な影響を与え、次の欠点もあります。
- 同期ブロッキング問題！実行中、参加しているすべてのノードはトランザクションをブロックしています。参加者がパブリックリソースを占有すると、他のサードパーティノードによるパブリックリソースへのアクセスもブロックされます。
- 単一障害点！コーディネーターの重要性のため、コーディネーターが失敗すると、参加者は引き続きブロックします。特に2番目の段階では、コーディネーターに障害が発生しても、すべての参加者がトランザクションリソースをロックしている状態にあり、トランザクション操作を完了できません。
- データに矛盾があります！2フェーズ送信プロセスでは、コーディネーターがコミット要求を参加者に送信したときに、ネットワーク異常またはサーバーのダウンタイムが発生しました。これにより、データ送信が部分的に成功し、送信が部分的に失敗し、データの不整合が発生します。
分散トランザクションを実装するためのメッセージミドルウェア+ HttpClient
分散システムでは、一般にシステムのユーザビリティが重視され、これに基づいて、CAPの定理をさらに拡張するために使用されるBASE理論が提案されています。BASE理論とは、
- 基本的に利用可能
- ソフト状態
- 最終的に一貫
BASE理論は、CAPでの一貫性と可用性のトレードオフの結果です。理論の中心的な考え方は、強力な一貫性を実現することはできませんが、各アプリケーションは適切な方法を使用して、独自のビジネス特性に従ってシステムを実現できます。結果の一貫性。このプロジェクトでは、Kafka + HttpClientを使用して、BASE理論に基づく分散トランザクションを実装しました。実装の考え方は次のとおりです。
- サービスコールの開始剤は、カフカによるメッセージを送信します。http情報サービスと呼ばれているだけでなく、成功と情報サービスコールバックサービスコールの発信元を失敗します。このとき、サービス呼び出し元のビジネスオブジェクトのステータスはソフトステータスを使用します。たとえば、注文ステータスは注文中です。
- 呼び出されたサービスのHTTPリクエストをリクエストするために、HTTPリクエストメッセージミドルウェアを転送するコンシューマーを作成します。呼び出されたサービスが正常に実行された後、HTTPリクエストによって返されたステータスに応じて、イニシエーターの成功サービスまたは失敗サービスを呼び出すコールバックサービスを決定します。これにより、サービスイニシエーターのサービスオブジェクトのステータスが最終的な整合性に到達できるようになります。 。
- メッセージが確実に消費されるようにするには、メッセージを送信するときに同期送信戦略を使用する必要があります。http要求情報を消費する場合、メッセージが消費を確認する必要がある後、パーティションオフセットを手動で送信して、メッセージを消費する必要があることを確認します。このとき、呼び出し先のhttp要求サービス、およびサービス開始者の成功サービスと失敗サービスは、べき等設計を満たす必要があります。
次の単一のサービスを例にとると、フローチャートは次のようになります。
残りの実装方法は、分散トランザクションについてのチャットを参照してから、ソリューションについて話すことができます
