eコマースWebサイトのバスケットへの並行性を管理するためのベストプラクティス


18

2人の顧客が在庫が1品目のみの製品を同時に追加する場合を管理するためのベストプラクティスは何ですか?

これら2人の顧客の1人が同じ製品を追加するのを避けるために、バスケットのコードにチェックが必要ですか?

または、このチェックは、たとえば、関連する製品がまだ在庫にあることを確認するための2番目のクエリ(同時顧客がまだ購入していないことを意味する)を行う際に、支払いフェーズで実行する必要がありますか?


あなたのための項目の劇場のチケット予約のようないくつかのサイトで、場所限られた時間のホールド、注文が処理されている間に
ブラッド・トーマス

回答:


10

この質問に対する完璧な答えはありません。すべては詳細に依存しています。

最初の「防衛線」として、可能な限り低い記事を売り切れないようにすることで、このような状況をまったく回避しようとします。これが可能かどうかは、状況と販売したい記事の種類によって異なります。私が働いている会社では、在庫がなくなる前に、記事はほとんどウェブサイトから削除されます。しかし、私たちは販売全体を販売しており、残りのいくつかの記事は販売員によって特別オファーとして販売されています。これは、特に高価格の記事を販売する場合、小さな店では選択肢にならないかもしれません。

バスケットに何かを追加するときに二重チェックを行うソリューションはあまり良くありません。人々は実際に注文することなくバスケットにたくさん入れます。そのため、一定期間この記事がブロックされる場合があります。

小規模な仕事に対する私の謙虚な意見では、最良の方法は、実際に注文が行われる支払いの直前に最終チェックを行うことです。最悪の場合は、今すぐ在庫切れになっていることを顧客に伝える必要があります(小さな店の場合はそれほど頻繁には発生しません)。


ナイスキャッチ-在庫が少なく、価格が高い
rohanagarwal

5

ベストプラクティスは、特定のビジネスケースに適したオプションを以下から選択することです。

  1. 楽観的オフラインロック

    ... 1つのセッションによってコミットされようとしている変更が別のセッションの変更と競合しないことを検証することによりこの問題(セッション競合の問題)を解決します。コミット前検証の成功とは、ある意味では、レコードデータの変更を続行してもよいことを示すロックを取得することです。検証と更新が単一のシステムトランザクション内で発生する限り、ビジネストランザクションは一貫性を表示します...

  2. 悲観的オフラインロック
    ...競合を完全に回避することで、競合を防ぎます。ビジネストランザクションがデータの使用を開始する前にデータのロックを取得するように強制するため、ほとんどの場合、ビジネストランザクションを開始すると、同時実行性にバウンスされずに完了することが確実になります。コントロール...
「ペシミスティックオフラインロックはセッションの競合の可能性が高いと想定してシステムの同時実行を制限するのに対し、オプティミスティックオフラインロックは競合の可能性は低いと想定します。セッションの競合により、複数のユーザーが同じデータを同時に。」


5

これは人の問題であり、データベースの問題でもあり、データベースのロックは簡単です!

顧客がチェックアウトすることはないかもしれないことを考えると…

次の2つの基本オプションがあります。

  • 顧客がアイテムをバスケットに追加した後、在庫レベルを再確認するか、再起動する必要がある時間(20分)の間、顧客のためにアイテムを予約します。これは、イベントや航空会社の座席のチケットによく使用されます。

  • または、「24時間以内に発送される通常の xxx」のように言いますが、チェックアウト時に在庫を予約します。この場合、一部のアイテムは在庫があるが他は在庫がない場合、チェックアウト後に注文をキャンセルできるようにする必要があります。(緑、黄、赤の在庫レベルもうまく機能します。または、一部のWebサイトでは、在庫が1または2になったときに「在庫不足」と表示されます)


2

いつものように、それはあなたの要件が何であるかに依存します。Amazonで1日に1億個のアイテムを販売している場合、プリエンプティブチェックとロックのオーバーヘッドはおそらく非常に高く、1日に1人の顧客がアイテムを取得できないという問題はごくわずかです。ユニークで高価な珍しいアンティークの宗教的なアイコンを扱う場合は、おそらく反対が当てはまります。あなたは、あなたのビジネスケースがそのスペクトルのどこに位置するかを自分で知っていなければなりません。


2

このケースでは、メッセージキューを使用して注文を処理し、FIFO方式で同じ製品で一度に1つのジョブのみを順番に処理するように構成しました。

注意点は、注文処理全体に新しいオーバーヘッドを追加しているため、少し遅れることです。


あなたは、唯一の消費者によって消費されるキュー制限している
rohanagarwal

1

ユーザーにとってのベストプラクティスは、2番目の追加が失敗することを確認することです。しかし、これは0.1%のケースのためにサイト全体を遅くします。

最も技術的に効率的なソリューションであり、売り上げを最大化するものは、それを成功させ、その後両方の注文を履行しようとすることです-ただ、現在在庫がないため、見つからないという意味ではありません非常時には。それができない場合、運が悪く謝罪したユーザーに連絡する必要があります。しかし、それがまさにクリスマス前に大騒ぎになったものです(これが登場した唯一の記事ではないので、Best Buyに謝罪しましたが、それは私が最初に見つけたものです)。

あなたの仕事は、ビジネスにすべてのオプションを賛否両論で提示し、アドバイスに基づいて彼らに決定させることです。売り上げを最大化するために、評判に時折小さな打撃を与える余裕があるなら、十分に公平です。できず、トラフィックが非常に少なく、二重更新をすばやく確認できる場合は、それも彼らの呼び出しです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.