1.冪等性:
いわゆる冪等性は、分散環境でよく見られる問題で、一般に、複数の操作を実行したときに得られる結果が同じになる、つまり、複数の操作の結果が一貫していることを意味します。
つまり、同じ操作に対して、ユーザーが 1 つの要求を開始した場合でも、複数の要求を開始した場合でも、最終的な実行結果は一貫しており、複数のクリックによる副作用はありません。
2. どのような状況で重複した送信が生成されるか (非冪等性)
次の状況では、べき等でない結果が生じます。
送信ボタンを 2 回続けてクリックする、
更新ボタンをクリックする、
ブラウザの戻るボタンを使用して前の操作を繰り返してフォームを繰り返し送信する、
ブラウザの履歴を使用してフォームを繰り返し送信する、
ブラウザが HTTP リクエストを繰り返す、など.
冪等性の核となる考え方は、このインターフェースの実行結果が一度だけ影響を受け、後で再度呼び出されてもデータに影響を与えないことを保証することです. したがって、そのような要件に基づいて、どのように解決しますか?冪等性の問題？
3. ソリューション
1. フロントエンドの js 送信禁止ボタンは、一部の js コンポーネントを使用できます
2. 送信後にページ リダイレクトを実行するには、Post/Redirect/Get モードを使用します
。これは、いわゆる Post-Redirect-Get (PRG) モードです。つまり、ユーザーがフォームを送信すると、クライアント側で送信成功メッセージ ページにリダイレクトされます。これにより、ユーザーが F5 キーを押すことによる送信の繰り返しが回避され、ブラウザー フォームの繰り返し送信の警告が表示されなくなり、ブラウザーを前後に押すことによって引き起こされる同じ問題も解消されます。
3. データベース操作の
挿入ユニーク インデックスを使用して、挿入されるデータが 1 つだけであることを確認します。また、悲観的ロックまたは楽観的ロックに基づいて、最初にクエリを実行してから判断することもできます.まず、データベースにデータがあるかどうかを確認します.存在する場合は、要求が要求されたことを証明し、要求が直接拒否された; 存在しない場合は、初めてであることが証明されます。.
4. セッション メカニズム (バックグラウンド サーバー) は、サーバー側で一意の識別子を生成し、それをセッションに格納し、フォームの非表示フィールドに書き込み、フォーム ページをブラウザーに送信します。 [送信] をクリックします。また、サーバー側では、フォーム内の隠しフィールドの値を取得し、セッション内の一意の識別子と比較し、等しい場合は最初の送信であることを意味し、このリクエストを処理してから削除します。セッション内の一意の識別子。等しくない場合は送信が繰り返されます。
5. Redis トークン メカニズム
各インターフェース リクエストの前にトークンを取得し、次のリクエストでこのトークンをリクエストのヘッダー ボディに追加し、バックグラウンドで検証します。検証に合格してトークンが削除された場合、次のリクエストで再度トークンが等しいかどうかを判断し、等しくない場合は送信を繰り返します。