そのため、問題は、当社の Web サイトで注文が重複しているケースがあることに気付いたときに始まりました。調査を開始したとき、ページで重複注文を引き起こす可能性があるものを絞り込むことができず、重複データの状態を説明できませんでした. 最も不気味な部分は、これらの注文が同じ瞬間 (最小ミリ秒まで) に作成されたことです。サーバーのアクセスログでも、リクエストは同時に受信されます。
さらに調査するためにランダムな顧客に電話をかけたところ、ほとんどの顧客は低速の接続 (一部はモデム経由) を使用しており、Chrome を使用しているというほぼ同じ回答でした。ほとんどのフィードバックは、ページが動かなくなったので戻るボタンを押したというものです。いくつかの検索の後、接続が遅い場合にページを取得するための積極的な手法である chrome の Http パイプライン機能について知りました。
ユーザーが [送信] ボタンを押す --> ajax JSON 呼び出し (GET) の確認 --> ajax JSON 呼び出しを介してフォーム データが POST される --> 顧客にフィードバックが返され、顧客がアクションを実行し、適切にリダイレクトされる.
これが AJAX または GET/POST 呼び出しの最適な使用法であるかどうかはわかりませんが、これは私が行き詰まっているものです。
この問題は非常に特殊な状況で発生するため (接続が遅く、Chrome は重複した接続を起動する必要があります)、正直なところ、これを再現することはできませんでした。しかし、ほぼ 95% のフィードバックが Chrome を指しているため、http パイプラインについて考える必要があります。複数のレコードが同時に作成されるように、リクエストを起動できる唯一の説明です。
また、http パイプライン処理は、POST 要求ではなく GET 要求に対してのみ行われることも知りました。したがって、次のことかどうかはわかりません。
これは AJAX POST リクエストをカバーします (私は jQuery を使用し、type:POST を使用します) Chrome が何らかの理由で (誤って) すべてのリクエストに対して複数のリクエストをスローする可能性があります (参照:余分なリクエストを送信する chrome をどうするか? )
Chrome の場合に私が見つけた唯一の議論は、http パイプラインがデフォルトで無効になっているということです。
両方のリクエストが同時に処理されているため、この場合に何をチェックすればよいかさえわかりません。同様のレコードが作成されているかどうかをチェックするためにバックエンドにチェックを入れることもできますが、それは高価なチェックであり、注文が遅くなり、ビジネスはそれを歓迎しない可能性があります.
http://www.chromium.org/developers/design-documents/network-stack/http-pipeliningで何かを見つけましたが、http パイプラインを停止する基準の 1 つを満たすためにリクエストを強制/ハックする必要があるかどうかはわかりません。
これをテストするためのポイントをいただければ幸いです。