大家應該都知道，秒殺為啥  用  異步隊列 這種形式來處理吧？哈哈 因為我們寫的程序功能之前常理都是  用戶請求到后臺，后臺操作數據庫進行實現相應功能。

上邊說道  用戶  -->  后臺服務器邏輯  -->數據庫

那么這樣的模式  如果用在秒殺上，  同時間 高并發來臨，后臺服務器邏輯操作數據庫  一定是數據庫 扛不住的時候，他已經就高潮了信不？

所以我們  如何讓服務器不癱瘓的實現秒殺咧？

就要使用我們 的一種快、高效  避免數據庫受到  高并發的請求處理；

實現思路：

1、在做一個  商品 開啟秒殺活動前，將數據庫中該商品的庫存  同步到我們的內容緩沖中例如  redis 、memcache 中；

2、然后  同時在redis、memcache內容緩沖中  構建我們的消息隊列A（其實也就是一塊命名了的  資源空間） 用來存放 客戶端的請求；

3、構建 處理 2 中的隊列數據 將處理的結果 放入另一個 隊列B中（例如 通過腳本 while()  sleep  實現隊列A處理后  結果再放入隊列B）；

4、客戶端點擊秒殺后，js等客戶端  啟動隔時 請求，去隊列B中找自己是不是被處理  以及處理的結果到底是個毛線 拿回來；

5、定時將 緩沖 中的商品庫存等信息  再同步回數據庫中

OK  幾句話是否點通了你？

實現腳本圖：

0.php   將數據庫商品庫存同步 緩沖中一份；

1.php   處理消息隊列A 的入隊（用戶的請求）；

2.php   while sleep腳本啟動，出隊A中的請求逐個處理  并將結果存入隊列B；

3.php   處理客戶端  定時請求讀取結果  隊列B中檢索；

4.html   定時請求3.php；

5.php    定時將緩沖商品信息同步回數據庫中

OK

以上，自己實現過一個例子，僅供參考