同時実行性の高い在庫のブロックを解決し、過剰在庫、フラッシュセール、不動産の強奪、宝くじなどを制御するための PHP のアイデアと方法。

現在、電子商取引業界では、フラッシュセールラッシュ購入活動が販売業者の一般的なプロモーション方法となっています。しかし、在庫数には限りがあるので、同時に注文する人が在庫数を超えてしまうと、売れすぎてしまったり、場合によっては在庫がマイナスになってしまうこともあります。 別の例: 電車のチケットの購入ラッシュ、フォーラムでの不動産の購入ラッシュ、宝くじ、さらには Weibo の人気のコメントも、ブロッキングの同時実行性の問題を引き起こす可能性があります。何も対策を講じないと、あっという間にサーバーが麻痺してしまう可能性があります。
より実現可能だと思うアイデアをいくつか紹介します:

オプション 1: メッセージ
queue を使用して実装する
は MemcacheQ などのメッセージ
queue に基づいて行うことができます。具体的な実装計画は表現してみましょうたとえば、ユーザーが取得できるチケットが 100 枚ある場合、ユーザーはこれら 100 枚のチケットをキャッシュに置き、読み取りおよび書き込み時にロックしないことができます。 同時実行の量が多い場合、約 500 人がチケットを取得できる可能性があるため、500 人以降のリクエストはイベントの終了時に静的ページに直接転送されます。 500人中400人が商品を手に入れることは不可能です。したがって、
キューに入った順に従って、最初の100名のみが正常に購入できます。次の 400 名はイベント終了ページに直接移動します。もちろん、500 人と入力するのは単なる例です。その数は自分で調整できます。アクティビティ終了ページでは、データベースではなく静的ページを使用する必要があります。これにより、データベースへの負担が軽減されます。
オプション 2: 複数のサーバーがある場合、オフロードの形で実装できます

m 個のチケットがあり、n 台の製品サーバーがリクエストを受信し、x 個のリクエストがルーティング サーバーによってランダムに転送されると仮定します
m/n 個のチケットを各製品サーバーに直接割り当てます
各製品サーバーのメモリに
カウンター を作成し、たとえば m/n*(1+0.1) 人の入場を許可します。 メモリ
カウンターがいっぱいの場合: 後から入る人はイベントが終了する静的ページに直接ジャンプし、
このサーバーにルーティングされなくなることをルーティングサーバーに通知します(これは議論する価値がある）。
すべての製品サーバーから入ってくる m/n*(1+0.1) 人が支払いサーバーに転送され、誰がより早いかを確認するために支払いプロセスに入ります。現時点では人数が少ないため、ロックか何かが簡単です。

オプション 3. 単一サーバーの場合は、Memcache ロックを使用して実装できます

product_key はチケット キーです
product_lock_key はチケット ロック キーです
product_key が memcached に存在する場合、すべてのユーザー注文手続きに入ることができます。
支払い手続きに入るときは、まずadd(product_lock_key, “1”)をmemcachedに格納し、
返品に成功したら支払い手続きに入ります。
失敗した場合は、誰かがすでに支払いプロセスに入っていることを意味し、スレッドは N 秒間待機して追加操作を再帰的に実行します。

オプション 4: ファイル排他ロックを使用する

注文リクエストを処理するときに、flock を使用してファイルをロックします。ロックが失敗した場合は、現時点では他の注文が処理中であることを意味します。または、ユーザーに直接「サーバーがビジーです」とプロンプトを表示します。 -ブロッキングモード:

<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX))
{
//..处理订单
flock($fp,LOCK_UN);
}
fclose($fp);
?>

上記では、行列、フラッシュセール、人数、カウンターなど、パニック買い、フラッシュセール、財産の強奪、宝くじなどの同時実行性の高い在庫の防止と制御をブロックする問題を解決するための PHP のアイデアと方法を紹介します。 PHP チュートリアルに興味のある友人が助けてくれることを願っています。