フラッシュ販売戦略は、eコマース業界でのプロモーションイベントやブランドマーケティングに一般的に使用されています。 この戦略は、プラットフォームに対するユニークビジター数と顧客ロイヤルティを増やすのに役立ちます。 優れたビジネスシステムにより、プラットフォームの安定性を向上させ、フラッシュ販売の公平性を確保できます。 これにより、ユーザーエクスペリエンスとプラットフォームの評判が向上し、フラッシュ販売のメリットが最大化されます。 このトピックでは、Tair (Redis OSS-compatible) のキャッシュ機能を使用して、フラッシュ販売を処理するための高度な同時並行ビジネスシステムを構築する方法について説明します。
フラッシュ販売の特徴
フラッシュ販売活動は、限られた期間内に指定された量の希少または特別な商品を販売するために使用されます。 これは多数のバイヤーを引き付けます。 ただし、プロモーションイベント中に注文できるのは少数のバイヤーだけです。 フラッシュセールスアクティビティは、プラットフォームでの定期的なセールスアクティビティと比較して、数十倍または数百倍のユニークビジターと注文リクエストの数を短期間で増加させます。
フラッシュ販売活動は3つのフェーズに分けられます。
プロモーションイベントの前に: バイヤーは商品の詳細ページを継続的に更新します。 その結果、このページに対する要求の数が急増する。
プロモーションイベント中: バイヤーは注文します。 注文要求の数がピークに達する。
プロモーションイベントの後: 注文を行った特定の購入者は、引き続き注文のステータスを照会するか、注文をキャンセルします。 ほとんどのバイヤーは、商品の詳細ページを更新し続け、他のバイヤーが注文をキャンセルした後、注文する機会を待ちます。
ほとんどの場合、データベースは行レベルのロックを使用して、購入者から送信されたリクエストを処理します。 データベースでは、ロックを保持する要求のみが在庫データを照会して注文することができます。 ただし、これらの場合、データベースは高い同時実行性を処理できません。 これにより、多数の要求によってサービスがブロックされ、サーバが購入者への応答を停止する可能性がある。
フラッシュ販売を処理するためのビジネスシステム
フラッシュ販売活動中に、ビジネスシステムは、大量のユーザトラフィックを受信することがある。 しかし、いくつかの要求のみが有効である。 システムアーキテクチャの階層を使用して、各フェーズで無効なリクエストを事前に特定してブロックできます。
ブラウザーキャッシュとContent Delivery Network (CDN) を使用して、静的コンテンツを要求するユーザートラフィックを処理する
フラッシュ販売活動の前に、バイヤーは商品詳細ページを継続的に更新します。 その結果、このページに対する要求の数が急増する。 この問題を解決するには、フラッシュ販売の商品の詳細と通常の商品の詳細を異なるwebページに表示する必要があります。 静的要素を使用して、フラッシュ販売の商品の詳細を表示します。 静的データは、ブラウザとCDNノードにキャッシュされます。ただし、ブラウザとサーバー間のやり取りが必要な配置順序機能を除きます。 このようにして、プロモーションがサーバーにリダイレクトされる前にページ更新によって発生したトラフィックのごく一部のみが発生します。
Tair (Redis OSS-compatible) の読み書き分離インスタンスを使用してコンテンツをキャッシュし、無効なリクエストをブロックする
CDNは、フェーズ1でユーザートラフィックをフィルタリングおよびブロックするために使用されます。 フェーズ2では、Tair (Redis OSS-compatible) の読み書き分離インスタンスを使用して、無効なリクエストをブロックできます。 フェーズ2では、ビジネスシステムがデータを取得します。 読み書き分離インスタンスは、1秒間に600,000を超えるクエリ (QPS) を処理でき、ビジネスの需要を満たすことができます。
データ制御モジュールを使用して、フラッシュ販売の商品のデータを読み書き分離インスタンスにキャッシュし、フラッシュ販売アクティビティが開始されるかどうかを示すタグを指定します。
"goodsId_count": 100 //The total number of commodities.
"goodsId_start": 0 //The flag that indicates whether the promotion activity begins.
"goodsId_access": 0 //The number of order requests that are accepted.
フラッシュ販売アクティビティが開始される前に、サーバークラスターによって取得されるgoodsId_startパラメーターの値は0です。 値0は、フラッシュ販売アクティビティが開始されていないことを示します。
データ制御モジュールがgoodsId_startパラメーターの値を1に変更すると、フラッシュ販売アクティビティが開始されます。
次に、サーバークラスターはgoodsId_startタグをキャッシュし、注文リクエストを受け入れます。 クラスターは、goodsId_accessで受け付けられた注文リクエストの数を更新します。 残りの商品の数は、次の式を使用して計算されます。goodsId_count - goodsId_access。
発注された注文の数がgoodsId_countの値に達した後、ビジネスシステムは後続の注文要求をブロックする。 残りの商品の数は0に設定される。
その結果、ビジネス・システムは注文要求のごく一部しか受け入れない。 同時実行性の高いシナリオでは、大量のトラフィックがシステムに向けられます。 この場合、システムが受け入れる注文リクエストの割合を制御できます。
Tair (Redis OSS-compatible) のマスターレプリカインスタンスを使用してインベントリデータをキャッシュし、インベントリからのアイテムの削除を高速化する
ビジネスシステムが注文要求を受信した後、システムは注文情報をチェックし、在庫から品目を除去する。 バックエンドデータベースから直接データを取得しないようにするには、Tair (Redis OSS-compatible) のマスターレプリカインスタンスを使用して、インベントリからアイテムを削除します。 マスターレプリカインスタンスは、100,000を超えるQPSをサポートしています。 Tair (Redis OSS-compatible) は、在庫クエリを最適化し、無効な注文リクエストをブロックし、ビジネスシステムの全体的なスループットを向上させてフラッシュ販売を処理するのに役立ちます。
データ制御モジュールを使用して、事前にインベントリデータをTair (Redis OSS-compatible) インスタンスにキャッシュできます。 インスタンスは、プロモーション用の商品データをハッシュテーブルに格納します。
"goodsId" : {
"Total": 100
"Booked": 0
}
goodsId
フィールドは、商品IDを示す。 合計
フィールドは、在庫内の商品の数を示します。 予約済み
フィールドは、注文された商品の数を示す。
在庫からアイテムを削除するには、フラッシュ販売促進サーバーは次のLuaスクリプトを実行し、Tair (Redis OSS-compatible) インスタンスに接続して注文権限を取得します。 Luaスクリプトは、Redisのシングルスレッドモデルに基づいて複数のコマンドのアトミック性を保証します。
local n = tonumber(ARGV[1])
if not n or n == 0 then
return 0
end
local vals = redis.call("HMGET", KEYS[1], "Total", "Booked");
local total = tonumber(vals[1])
local blocked = tonumber(vals[2])
if not total or not blocked then
return 0
end
if blocked + n <= total then
redis.call("HINCRBY", KEYS[1], "Booked", n)
return n;
end
return 0
SCRIPT LOAD
コマンドを実行して、Luaスクリプトを事前にTair (Redis OSS-compatible) インスタンスにキャッシュします。 次に、EVALSHA
コマンドを実行してスクリプトを実行します。 この方法では、EVAL
コマンドを直接実行するよりもネットワーク帯域幅が少なくて済みます。
LuaスクリプトをTair (Redis OSS-compatible) インスタンスにキャッシュします。
SCRIPT LOAD "lua code"
次の応答が返されます。
"438dd755f3fe0d32771753eb57f075b18fed7716"
Luaスクリプトを実行します。
EVALSHA 438dd755f3fe0d32771753eb57f075b18fed7716 1 goodsId 1
次の結果が返されます。 結果は、アイテムがインベントリから削除されたことを示します。
(integer) 1
説明この場合、HGET goodsId Bookedコマンドを実行すると、戻り値は
"1"
になります。 戻り値は、商品が注文されたことを示す。
Tair (Redis OSS-compatible) インスタンスが、購入者が注文した商品の数として値nを返した場合、アイテムはインベントリから正常に削除されます。
Tair (Redis OSS-compatible) のマスターレプリカインスタンスを使用して、メッセージキューに基づいて注文データをデータベースに非同期に書き込む
品目が在庫から除去された後、フラッシュ販売システムは、注文データをデータベースに書き込む。 システムは、少数の商品についてデータベース内の操作を直接実行することができる。 プロモーション対象の商品の数が10,000 100,000を超えると、ロックの競合が発生し、データベースのパフォーマンスのボトルネックが発生する可能性があります。 したがって、データをデータベースに直接書き込むことを防止するために、フラッシュ販売システムは、注文データをメッセージキューに書き込む。 メッセージキューに書き込まれた注文は、正常に発注された注文と見なされます。
Tair (Redis OSS-compatible) インスタンスは、リスト構造のメッセージキューを提供します。
orderList { [0] = {Order content} [1] = {Order content} [2] = {Order content} ... }
フラッシュ販売システムは、注文コンテンツをTair (Redis OSS-compatible) インスタンスに書き込みます。
LPUSH orderList {Order content}
非同期注文モジュールは、Tair (Redis OSS-compatible) インスタンスから注文データを順次取得し、注文データをデータベースに書き込みます。
BRPOP orderList 0
Tair (Redis OSS-compatible) インスタンスは、注文リクエストをキューに入れ、注文データをデータベースに非同期に書き込み、発注プロセスを高速化します。
データ制御モジュールを使用してプロモーションデータの同期を管理する
プロモーションの開始時に、フラッシュ販売システムはTairの読み書き分離インスタンス (Redis OSS互換) を使用して無効なトラフィックをブロックし、有効なトラフィックの一部が注文プロセスを続行できるようにします。 プロモーション後、フラッシュ販売システムは、注文認証の失敗と払い戻し要求によって引き起こされるより多くのトラフィックを処理する必要があります。 したがって、データ制御モジュールは、データベース内のデータを定期的に計算し、そのデータをマスターレプリカインスタンスに同期してから、読み書き分離インスタンスに同期します。