PHP如何應對秒殺搶購高並發思路

我們常用QPS（Query Per Second，每秒處理請求數）來衡量一個web應用的吞吐率，解決每秒數萬次的高並發場景，這個指標非常關鍵。

舉個栗子：假設一個業務請求平均為100ms，同時系統內有20台apache web伺服器，MaxClients（apache的最大連接數）設置為500，那麼理論QPS峰值就是20*500/0.1=100000（理論與實際肯定有差異）。

這系統貌似理論上來說很強大，1秒鐘處理100000個請求，實際當然沒有這麼理想。在高並發的實際場景下，機器都處於高負載的狀態，在這個時候平均響應時間會被大大增加。

就Web伺服器而言，Apache打開了越多的連接進程，CPU需要處理的上下文切換也越多，額外增加了CPU的消耗，然後就直接導致平均響應時間增加。因此上述的MaxClient數目，要根據CPU、內存等硬體因素綜合考慮，絕對不是越多越好。

可以通過Apache自帶的abench來測試一下，取一個合適的值。然後，我們選擇內存操作級別的存儲的Redis，在高並發的狀態下，存儲的響應時間至關重要。網路帶寬雖然也是一個因素，不過，這種請求數據包一般比較小，一般很少成為請求的瓶頸。負載均衡成為系統瓶頸的情況比較少，在這裡不做討論。

那麼問題來了，假設我們的系統，在5w/s的高並髮狀態下，平均響應時間從100ms變為250ms（實際情況，甚至更多）：

20*500/0.25 = 40000 （4萬QPS）

於是，我們的系統剩下了4w的QPS，面對5w每秒的請求，中間相差了1w。

舉個例子，高速路口，1秒鐘來5部車，每秒通過5部車，高速路口運作正常。突然，這個路口1秒鐘只能通過4部車，車流量仍然依舊，結果必定出現大塞車。（5條車道忽然變成4條車道的感覺）

同理，某一個秒內，20*500個可用連接進程都在滿負荷工作中，卻仍然有1萬個新來請求，沒有連接進程可用，系統陷入到異常狀態也是預期之內。

其實在正常的非高並發的業務場景中，也有類似的情況出現，某個業務請求介面出現問題，響應時間極慢，將整個Web請求響應時間拉得很長，逐漸將Web伺服器的可用連接數佔滿，其他正常的業務請求，無連接進程可用。

更可怕的問題是用戶的行為特點，系統越是不可用，用戶的點擊越頻繁，惡性循環最終導致「雪崩」（其中一台Web機器掛了，導致流量分散到其他正常工作的機器上，再導致正常的機器也掛，然後惡性循環），將整個Web系統拖垮。

重啟與過載保護

如果系統發生「雪崩」，貿然重啟服務，是無法解決問題的。最常見的現象是，啟動起來後，立刻掛掉。這個時候，最好在入口層將流量拒絕，然後再重啟。如果是redis/memcache這種服務也掛了，重啟的時候需要注意「預熱」，並且很可能需要比較長的時間。

秒殺和搶購的場景，流量往往是超乎我們系統的準備和想像的。這個時候，過載保護是必要的。如果檢測到系統滿負載狀態，拒絕請求也是一種保護措施。在前端設置過濾是最簡單的方式，但是，這種做法是被用戶「千夫所指」的行為。更合適一點的是，將過載保護設置在CGI入口層，快速將客戶的直接請求返回。

高並發下的數據安全

我們知道在多線程寫入同一個文件的時候，會存現「線程安全」的問題（多個線程同時運行同一段代碼，如果每次運行結果和單線程運行的結果是一樣的，結果和預期相同，就是線程安全的）。

如果是MySQL資料庫，可以使用它自帶的鎖機制很好的解決問題，但是，在大規模並發的場景中，是不推薦使用MySQL的。秒殺和搶購的場景中，還有另外一個問題，就是「超發」，如果在這方面控制不慎，會產生髮送過多的情況。

我們也曾經聽說過，某些電商搞搶購活動，買家成功拍下後，商家卻不承認訂單有效，拒絕發貨。這裡的問題，也許並不一定是商家奸詐，而是系統技術層面存在超發風險導致的。

超發的原因

假設某個搶購場景中，我們一共只有100個商品，在最後一刻，我們已經消耗了99個商品，僅剩最後一個。這個時候，系統發來多個並發請求，這批請求讀取到的商品餘量都是99個，然後都通過了這一個餘量判斷，最終導致超發。（導致了並發用戶B也「搶購成功」，多讓一個人獲得了商品。這種場景，在高並發的情況下非常容易出現。）

優化方案1

將庫存欄位number欄位設為unsigned，當庫存為0時，因為欄位不能為負數，將會返回false。

解決線程安全的思路很多，可以從「悲觀鎖」的方向開始討論。

悲觀鎖，也就是在修改數據的時候，採用鎖定狀態，排斥外部請求的修改。遇到加鎖的狀態，就必須等待。

雖然上述的方案的確解決了線程安全的問題，但是，別忘記，我們的場景是「高並發」。也就是說，會很多這樣的修改請求，每個請求都需要等待「鎖」，某些線程可能永遠都沒有機會搶到這個「鎖」，這種請求就會死在那裡。同時，這種請求會很多，瞬間增大系統的平均響應時間，結果是可用連接數被耗盡，系統陷入異常。

優化方案2

使用MySQL的事務，鎖住操作的行

FIFO隊列思路

那好，那麼我們稍微修改一下上面的場景，我們直接將請求放入隊列中，採用FIFO（First Input First Output，先進先出），這樣的話，我們就不會導致某些請求永遠獲取不到鎖。看到這裡，是不是有點強行將多線程變成單線程的感覺哈。

然後，我們現在解決了鎖的問題，全部請求採用「先進先出」的隊列方式來處理。那麼新的問題來了，高並發的場景下，因為請求很多，很可能一瞬間將隊列內存「撐爆」，然後系統又陷入到了異常狀態。

或者設計一個極大的內存隊列，也是一種方案，但是，系統處理完一個隊列內請求的速度根本無法和瘋狂湧入隊列中的數目相比。也就是說，隊列內的請求會越積累越多，最終Web系統平均響應時候還是會大幅下降，系統還是陷入異常。

文件鎖的思路

對於日IP不高或者說並發數不是很大的應用，一般不用考慮這些！用一般的文件操作方法完全沒有問題。但如果並發高，在我們對文件進行讀寫操作時，很有可能多個進程對進一文件進行操作，如果這時不對文件的訪問進行相應的獨佔，就容易造成數據丟失。

優化方案4

使用非阻塞的文件排他鎖

樂觀鎖思路

這個時候，我們就可以討論一下「樂觀鎖」的思路了。樂觀鎖，是相對於「悲觀鎖」採用更為寬鬆的加鎖機制，大都是採用帶版本號（Version）更新。

實現就是，這個數據所有請求都有資格去修改，但會獲得一個該數據的版本號，只有版本號符合的才能更新成功，其他的返回搶購失敗。這樣的話，我們就不需要考慮隊列的問題，不過，它會增大CPU的計算開銷。但是，綜合來說，這是一個比較好的解決方案。

有很多軟體和服務都有「樂觀鎖」功能的支持，例如Redis中的watch就是其中之一。通過這個實現，我們保證了數據的安全。

優化方案5

Redis中的watch

文章來源：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！