3

私は非常に急なトラフィックを経験するオンラインストアを運営しています。最近、ペイメントゲートウェイに何らかの問題が発生したため、大規模なセールイベント中にシステム全体が停止し、APIからの応答に通常の2〜3秒ではなく17秒かかりました。何百人もの人々が同時に購入を試みました。これにより、本番クラスター内のすべてのWebサーバーのすべてのWebワーカースレッドが、支払いゲートウェイからのAPI応答を待機することになりました。本番クラスター全体がロックされ、どのページも提供できませんでした。

この問題の1つの解決策は、Resqueを使用してバックグラウンドで支払いを処理することです。Webサーバーは、「支払いは処理中です...」などの応答をユーザーにすぐに返します。Webサーバーは、次のWeb要求に進むことができます。

問題は、支払いが処理された後もチェックアウトを続行することです。多くの顧客がJavaScriptを持っていないため、AJAXを使用してトランザクションが完了したかどうかをポーリングすることはできません。私はそれに頼ることができません。「処理中...」ページでチェックアウトの割合が停止すると、高価なカスタマーサポートの問題が発生するため、JavaScriptや信頼性の低いサーバープッシュテクノロジーは使用したくありません。

トランザクションをバックグラウンドで確実に処理できるように、ページフローをどのように設計できますか？

4

4 に答える 4

0

ギアマンを試しましたか？

http://gearman.org/

于 2012-05-14T18:24:55.937 に答える
0

はい。「処理中です。確認メールをお送りします。」と返信します。バックグラウンドプロセスにリンクを記載したメールを送信してもらい、結果を示すレコードにマークを付けます。その後、顧客は再度確認するか、電子メールを待って再度確認することができます。

AJAXで行うことはすべて、AJAXリクエストに応答するサーバーを拘束します。同じ問題。リクエストが単に「十分に低いが低すぎない」頻度で結果をポーリングしている場合を除きます。ポーリングは通知よりも醜いです。

于 2012-06-23T23:29:10.400 に答える
0

Javascriptが有効になっているクライアントに頼ることはできないとおっしゃっていましたが、クライアント側のスクリプトなしでこれを実現しようとするのは賢明ではないと思います。

  1. たとえば、ユーザーに更新ボタンをクリックし続けてHTTPリクエストを生成し、サーバーから支払いトランザクションのステータス（「処理中」、「成功」、「失敗」のいずれか）を完了するまでプルバックすることができます。しかし、それは不格好です。

  2. または、少し良いエクスペリエンスを得るには、メタリフレッシュ命令を使用してリフレッシュを自動化しますが、それでもサイトは古風に見えます。

    <meta http-equiv = "refresh" content = "2; url = http：//site.com/checkout/？session = 123" />

  3. しかし、私の強い好みは、代わりにクライアント側の動作を使用することです。すぐに表示を変更するために使用します。選択したAJAXライブラリ、JQuery、または単にJavascriptを使用します。DOMを操作して、「処理中」のメッセージのみを表示します。または、既存のページ要素をそのままにしておく場合は、ユーザーによるダブルクリックを防ぐために、フォームのすべてのボタンまたはその他の送信可能な部分が無効になっていることを確認してください。そして、支払いが数秒かかることをユーザーに警告します。支払いが処理されると、支払いの失敗または成功のいずれかがあったことを示すために、画面を進めるためにHTTP応答が到着します。

これらのアプローチはすべて、支払いサーバーがトランザクションを処理するのにかかる時間についての心配をなくすはずです。サーバー側に問題がある場合は、解決すべき別の問題です。

于 2012-05-15T06:20:00.563 に答える
0

イベントベースのソリューション（たとえば、EventMachine）を調べて、これらの要求を処理するようにします。このシナリオでは、標準のRoRサーバーはすべて崩壊します。javascriptを使用したある種のバックエンド処理は間違いなくこれを解決する最も簡単な方法ですが、それがオプションでない場合は、APIが永久に応答しないなどを処理するように設計されたものにそのフローを移動することを検討します。

于 2012-05-14T03:49:32.430 に答える