最近在做一個課程的購買功能，微信支付，以後可能會做團購或者拼團等功能，所以今天想找一找有關秒殺高併發的問題。
我理解的方法如下：
用另外的單進程處理隊列，下單請求都放到隊列中，一個一個的處理
在更新數據庫中庫存數的時候，根據update的結果來判斷，where 庫存 > 0，返回值如果是false，回滾
數據庫樂觀鎖，先查詢庫存，將庫存加一，然後生成訂單，更新庫存的時候再查一次庫存，是否跟預期的庫存一致，不一致就回滾
藉助文件排他鎖，在處理下單請求的時候，用flock鎖定一個文件，如果鎖定失敗說明有其他訂單正在處理，此時要麼等待要麼直接提示用戶"服務器繁忙"
阻塞(等待)模式
<?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);
?>
下面是從其他地方扒來的，原地址是：http://www.cnblogs.com/zxz1987/p/6538216.html
1.使用消息隊列 我們常用到Memcache、Radis。 比如：有100張票可供用戶搶，那麼就可以把這100張票放到緩存中，讀寫時不要加鎖。 當併發量大的時候，可能有500人左右搶票成功，這樣對於500後面的請求可以直接轉到活動結束的靜態頁面。進去的500個人中有400個人是不可能獲得商品的。所以可以根據進入隊列的先後順序只能前100個人購買成功。後面400個人就直接轉到活動結束頁面。當然進去500個人只是舉個例子，至於多少可以自己調整。而活動結束頁面一定要用靜態頁面，不要用數據庫。這樣就減輕了數據庫的壓力。
2.如果是分佈式集羣服務器，就需要一個或多個隊列服務器 ，小米和淘寶的搶購還是有稍許不同的，小米重在搶的那瞬間，搶到了名額，就是你的，你就可以下單結算。而淘寶則重在付款的時候的過濾，做了多層過濾，比如要賣10件商品，他會讓大於10的用戶搶到，在付款的時候再進行併發過濾，一層層的減少一瞬間的併發量。
3.使用Memcache鎖 product_lock_key 爲票鎖key 當product_key存在於memcached中時，所有用戶都可以進入下單流程。 當進入支付流程時，首先往memcached存放add(product_lock_key, “1″),如果返回成功，進入支付流程。如果不成，則說明已經有人進入支付流程，則線程等待N秒，遞歸執行add操作。
總結來說，可以從隊列（memcache，redis，分層處理高併發），文件鎖，數據庫（如果單純用數據庫操作的話，壓力會不會過大？）三方面來操作，需要後續繼續研究實踐
-----我是回來編輯的分割線-----
附上一篇php大數據處理算法總結http://blog.csdn.net/fableboy/article/details/18869973
-----我是又回來編輯的分割線-----
嗯，這篇也不錯
http://www.360doc.com/content/16/1202/16/13478832_611330547.shtml