私の状況では、私はページを持っていて、売り手はクライアントの注文を受けようとしています。クライアントの注文後、売り手は確認ボタンを押して、クライアントが身分証明書を渡すのを待ちます。これは ajax リクエストで行います。製品のリスト、メッセージ、キャンセル ボタンを含むダイアログが表示されます。
私のajaxがサーバー側に送信された後、ユーザーがカードを渡したかどうかを確認するために「スリープ」を使用して「for」を実行しています。 ）。問題は、ユーザーがプロセスをキャンセルすることを決定した場合、サーバー側の最初のリクエストでビジーであり、その戻りを待っているため、キャンセル ajax リクエストを機能させることができないことです。
誰でもそれについて提案はありませんか？サイトのワークフローが次のように機能することを本当に望んでいました。
クライアントの注文 -> 売り手がアイテムを追加してヒットを確認 -> クライアントが確認に合格するか、売り手がキャンセルできる -> プロセスの終了
あなたが行っている方法でそれを行う簡単な方法があったとしても、このプロセスは、ほんの一握り以上の接続の後、サーバーをすぐに圧倒します.
顧客の識別を要求する前に、顧客の注文をデータベースに保存し、注文のステータスフィールドを「識別待ち」に設定するか、そのようなものにします。次に、PHP スクリプトを待機させずに識別フローを続行し、多くのリソースを節約できます。
クライアントがうっかり切断した場合でも、注文は保存されているので、後で本人確認を完了することができます。
最後に、クライアントが正常に識別を完了したら、注文のステータス フィールドを「認証済み」に更新して、処理の準備ができていることを示すことができます。
編集: 特定の問題に対処するには、次のフローを検討してください。
注文を「保留中の識別」として保存し、「待機中...」ダイアログを表示します。
ダイアログをいつ閉じる必要があるかを知るために、注文のステータスが変更されたかどうかを尋ねる非常に単純なリクエストを数秒ごとに実行します。
ある時点で、識別デバイスが確認要求を送信し、注文を取得してステータスを変更します。次に、手順 2 で実装した定期的な呼び出しが開始され、ダイアログが非表示になります。
セッションは一時的なストレージ メディアとしては適切な場所ではありませんが、Redis、Memcached、または同様のサービスは、デバイスとサイトが何らかの方法で情報を共有できることを考えると、そのプロセスを簡素化するのに役立ちます。