在秒殺、搶火車票等地方，咱們一般用遇到這樣高併發的問題

在秒殺、搶火車票等地方，咱們一般用遇到這樣高併發的問題，
下面我提供了四種解決方案：
一、使用文件鎖
$fp=fopen("order.lock","r");
if(flock($fp,LOCK_EX)){
//..處理訂單的代碼flock($fp,LOCK_UN);
}
fclose($fp);
————————————————————————————————————————————————————————
二、使用消息隊列咱們經常使用到Memcacheq、Radis。
好比：有100張票可供用戶搶，那麼就能夠把這100張票放到緩存中，讀寫時不要加鎖。
當併發量大的時候，可能有500人左右搶票成功，這樣對於500後面的請求能夠直接轉到活動結束的靜態頁面。
進去的500我的中有400我的是不可能得到商品的。
因此能夠根據進入隊列的前後順序只能前100我的購買成功。
後面400我的就直接轉到活動結束頁面。
固然進去500我的只是舉個例子，至於多少能夠本身調整。
而活動結束頁面必定要用靜態頁面，不要用數據庫。
這樣就減輕了數據庫的壓力。
—————————————————————————————————————————————————————————
三、若是是分佈式集羣服務器，就須要一個或多個隊列服務器小米和淘寶的搶購仍是有稍許不一樣的，
小米重在搶的那瞬間，搶到了名額，就是你的，你就能夠下單結算。
而淘寶則重在付款的時候的過濾，作了多層過濾，好比要賣10件商品，
他會讓大於10的用戶搶到，在付款的時候再進行併發過濾，一層層的減小一瞬間的併發量。
—————————————————————————————————————————————————————————
四、使用Memcache鎖
product_lock_key 爲票鎖key
當product_key存在於memcached中時，全部用戶均可以進入下單流程。
當進入支付流程時，首先往memcached存放add(product_lock_key, 「1″),
若是返回成功，進入支付流程。
若是不成，則說明已經有人進入支付流程，則線程等待N秒，do while遞歸執行add操做。