轉載鏈接：http://www.4u4v.net/thinking-approach-to-buy-spike-grab-floor-sweepstakes-and-other-high-concurrent-blocking-prevention-excess-inventory-solve-php.html

如今在電商行業里,秒殺搶購活動已經是商家常用促銷手段。但是庫存數量有限，而同時下單人數超過了庫存量，就會導致商品超賣甚至庫存變負數的問題。
又比如：搶購火車票、論壇搶樓、抽獎乃至爆紅微博評論等也會引發阻塞式高并發問題。如果不做任何措施可能在高瞬間造成服務器癱瘓，如何解決這個問題呢？
這里提出個人認為比較可行的幾個思路方法：

方案一：使用消息隊列來實現

可以基于例如MemcacheQ等這樣的消息隊列，具體的實現方案這么表述吧
比如有100張票可供用戶搶，那么就可以把這100張票放到緩存中，讀寫時不要加鎖。 當并發量大的時候，可能有500人左右搶票成功，這樣對于500后面的請求可以直接轉到活動結束的靜態頁面。進去的500個人中有400個人是不可能獲得商品的。所以可以根據進入隊列的先后順序只能前100個人購買成功。后面400個人就直接轉到活動結束頁面。當然進去500個人只是舉個例子，至于多少可以自己調整。而活動結束頁面一定要用靜態頁面，不要用數據庫。這樣就減輕了數據庫的壓力。

方案二：當有多臺服務器時，可以采用分流的形式實現

假設有m張票, 有n臺產品服務器接收請求,有x個請求路由服務器隨機轉發
直接給每臺產品服務器分配 m/n張票
每臺產品服務器內存做計數器,比如允許m/n*(1+0.1)個人進來。
當內存計數器已滿：
后面進的人, 直接跳到到轉到活動結束的靜態頁面，
通知路由服務器,不在路由到這臺服務器(這個值得商討)。
所有產品服務器進來的m/n*(1+0.1)個人再全部轉發到一臺付款服務器上,進入付款環節,看誰手快了,這時候人少,加鎖什么的就簡單的。

方案三、如果是單服務器，可以使用Memcache鎖來實現

product_key 為票的key
product_lock_key 為票鎖key
當product_key存在于memcached中時，所有用戶都可以進入下單流程。
當進入支付流程時，首先往memcached存放add(product_lock_key, “1″),
如果返回成功，進入支付流程。
如果不成，則說明已經有人進入支付流程，則線程等待N秒，遞歸執行add操作。

方案四、借助文件排他鎖

在處理下單請求的時候，用flock鎖定一個文件，如果鎖定失敗說明有其他訂單正在處理，此時要么等待要么直接提示用戶"服務器繁忙"
本文要說的是第4種方案，大致代碼如下

阻塞(等待)模式：

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

非阻塞模式：

<?php
$fp = fopen("lock.txt", "w+");
if(flock($fp,LOCK_EX | LOCK_NB))
{//..處理訂單flock($fp,LOCK_UN);
}
else
{echo "系統繁忙，請稍后再試";
}fclose($fp);
?>

方案五、管道鎖與庫存控制

入口我們看做一個管道(tube)，假定每一個購票者給大概5分鐘可以完成購票，那么超過5分鐘后或者已經買到票，就會讓出位置讓后面的人進入售票大廳，當然這是理想化想法，但至少我們把壓力控制在我們可以處理的能力之內，要不然服務器宕機，欲哭無淚。

創建管道：

/**
* 創建管道　默認30個入口
* @param string $tubeName
* @param int $max
* @return bool
*/
static public function createTube($tubeName, $max = 30) {if (!$beanstalk = Common::getBeanstalkHandle()) return false;$beanstalk->use_tube($tubeName);$i = 0;while ($i < $max) {$beanstalk->put(1);$i++;}return true;
}

實現管道鎖

/**
* 采用管道方式進行加鎖，以限制同時進行某個流程的并發數
* @param string $name　管道名稱
* @param int $delay　出管理延遲時間默認為5秒
* @return bool
*/
public function tubeLock($name, $delay = 5) {$beanstalk = Common::getBeanstalkHandle();$beanstalk->watch($name);$return = false;$job = $beanstalk->reserve_with_timeout();if ($job['id'] > 0) $return = $beanstalk->release($job['id'], 1024, $delay);$beanstalk->ignore($name);return $return;
}

提前創建好管道，在并發流程中：


到此為止，如我們所愿，我們已經控制了并發，我們已經把我們能力范圍內可以控制的人放進來了，其它人只能繼續等待...
剩下就是庫存問題了，庫存控制原則：

庫存數不能<0，否則問題大了，商品超賣了，用戶下了單，但沒貨發給賣家，那你就等著投訴吧。

請看下面一個sql(數據庫是InnoDB):

/**
*
* 更新庫存
* @param int $num
* @param int $id
*/
public function updateQuantity($num, $<span style="background-color: rgb(255, 255, 255); ">goodsid</span>) {$sqlPart = $num < 0 ? ' AND quantity >= ' . abs($num) : '';$sql = 'UPDATE %s SET quantity = quantity + ?, sale_num = sale_num - ? WHERE id = ?' . $sqlPart;return $this->_update($sql, array(intval($num), intval($num), intval($goodsid));
}

重點看sqlPart部分，這里巧妙和利用mysql的行級鎖，把庫存不可能為0的控制權交給了mysql來處理，此乃點晴之筆。

補充說明：
我通過你的問題，想象了一下你的環境。
可能會有100張票，但1萬人搶。
你可以在服務器上做一個消息列隊。不論多少人搶票，都先放入消息列隊中。這樣，我們就把高并發，變成了統一的單線程。
這時候一切都好辦了。優點是緩解了MYSQL的瞬時壓力
但缺點是，如果1秒內1萬人點擊搶票。有可能會造成瞬時用戶訪問困難。（因為大家都在列隊）
如果你覺得慢了幾百毫秒不能忍，那你就需要換一個做法：
做一個競爭鎖，防止多個用戶同時獲取一張票。（票在MYSQL中）
在內存中存入一個標簽，來確定是否還有票。
當內存標簽說：沒有票了。 剩下的用戶一律歇菜。
這樣的優點是不論MYSQL，還是用戶，都很輕松。
缺點是，稍微有點小麻煩。 看你具體需求了。