redis php 秒殺

想瞭解下秒殺系統的設計 於是百度如下

1. 訪問壓力 即使是單純靜態頁面 高並發下也是需要加機器的 解決方案 增加伺服器 負載平衡
2. 處理請求 網上有講用redis隊列緩衝請求 然後取秒殺商品數量記錄返回秒殺成功 其他秒殺失敗 秒殺結束或者庫存為0 停止排入佇列
3. 庫存準確性需要特殊處理嗎（使用隊列的情況下）？
4. 限流（隨機1%的請求通過 99%直接返回失敗）這一點我覺得小米的預約做的很好 沒預約的直接無法進入搶購系統

但是對具體實現有很多疑問
比如：
使用者的請求是什麼樣的過程，從請求到返回結果？
redis隊列解決了那些問題？
負載平衡查詢redis伺服器？
整個過程不需要mysql參與吧？
秒殺商品資料緩衝在redis？
如果使用者秒到了 僅僅是redis標記這個人有購買資格而已吧 當進入購買時查詢這個資格有則建立訂單 理解對嗎？

求大神解惑

回複內容：

想瞭解下秒殺系統的設計 於是百度如下

1. 訪問壓力 即使是單純靜態頁面 高並發下也是需要加機器的 解決方案 增加伺服器 負載平衡
2. 處理請求 網上有講用redis隊列緩衝請求 然後取秒殺商品數量記錄返回秒殺成功 其他秒殺失敗 秒殺結束或者庫存為0 停止排入佇列
3. 庫存準確性需要特殊處理嗎（使用隊列的情況下）？
4. 限流（隨機1%的請求通過 99%直接返回失敗）這一點我覺得小米的預約做的很好 沒預約的直接無法進入搶購系統

但是對具體實現有很多疑問
比如：
使用者的請求是什麼樣的過程，從請求到返回結果？
redis隊列解決了那些問題？
負載平衡查詢redis伺服器？
整個過程不需要mysql參與吧？
秒殺商品資料緩衝在redis？
如果使用者秒到了 僅僅是redis標記這個人有購買資格而已吧 當進入購買時查詢這個資格有則建立訂單 理解對嗎？

求大神解惑

使用者請求：
使用者進入代理機，代理機把請求分發給後端某一個web伺服器，web伺服器拿到使用者請求以後通過php操作資料庫或者redis，然後把結果返回給web伺服器，最後呈現給使用者。

redis隊列主要解決了大並發的問題，因為他是隊列的形式，一條一條處理的，不會造成因為並發大幾個人同時更新一條資料，你想想看，如果有幾百人的並發，沒有用到redis，你的搶購資格是有限的，因為資料庫緩衝或者memcache的某些原因，幾個人同時查到有一個搶購資格，結果都在update這條資料，造成的結果可能就是最後一個人update這條資料的人獲得真正的搶購資格，其他人被他更新掉了，但是其他人前台返回的是已經搶到了。

正常來說，是不用mysql的，因為你的搶購資格，都會緩衝在redis裡面，看具體需求。

我也是菜鳥，大神勿噴。

採用層層過濾的思想來設計秒殺，前置nosql資料庫過濾大多數使用者，具體數字可以為庫存的放大2到10倍，接下入隊列，後端消費者接收隊列訊息，然後操作mysql資料庫進行更新下單，減庫存。前台輪詢結果

頂一下 求解

秒殺系統不要將流量都到落到幕後處理伺服器上，你有200個秒殺的產品，放前1000個使用者過來就足夠了（放200w個進來幹嘛，純粹累伺服器）；
通過這麼一過濾，根本沒有什麼壓力嘛；

