次の方法で共有


同一入力のための Azure Functions の設計

イベント ドリブン アーキテクチャとメッセージ ベースのアーキテクチャでは、現実では、データの整合性とシステムの安定性を維持しながら、同一の要求を受け入れる必要があります。

例として、エレベーターの呼び出しボタンを考えてみます。 あなたがボタンを押すと、ボタンが点灯し、エレベーターはあなたがいる階に送られます。 少しして、別の人物がエレベーターに乗るためにあなたの傍にやって来ました。 その人物はあなたに笑顔を見せた後、点灯しているボタンを押しました (2 回目)。 あなたは笑顔を返し、エレベーターを呼び出すためのコマンドはべき等であることを思い出して独りでクスクス笑いました。

エレベーターの呼び出しボタンは、2 回押しても、3 回押しても、4 回押しても、最終的な結果にはまったく影響しません。 ボタンが押されると、その回数に関係なく、エレベーターは、あなたがいる階に送られます。 エレベーターのようなべき等システムでは、同じコマンドが何回実行されても、同じ結果が発生します。

アプリケーションをビルドするときは、次のシナリオを検討してください。

  • 在庫管理アプリケーションで、同じ製品の削除が複数回試行されたらどうなるか。
  • 同一人物の従業員レコードを作成するための要求が複数ある場合、人事アプリケーションはどのように動作するか。
  • バンキング アプリで同一の引き出しを行う要求が 100 回取得された場合、金銭はどこに行くのか。

関数に対する要求で同一のコマンドが受信される可能性があるコンテキストは多数あります。 次のような状況があります。

  • 同じ要求を何度も送信する再試行ポリシー
  • アプリケーションに対して再生されるキャッシュされたコマンド
  • 同一の要求を複数回送信するアプリケーション エラー

データの整合性とシステムの正常性を保護するために、べき等アプリケーションには、次の動作を含む可能性のあるロジックが含まれています。

  • 削除を実行する前にデータが存在することを確認する
  • 作成操作を実行する前にデータが既に存在するかどうかを確認する
  • データを最終的に整合させる調整ロジック
  • コンカレンシー制御
  • 重複検出
  • データの鮮度の検証
  • 入力データを検証するガード ロジック

最終的に、べき等性は、特定のアクションが可能であり、一度だけ実行されることを保証することで実現されます。

次の手順