文章來自微信公眾號：PHP自學中心
前臺
在秒殺系統中，前臺主要面對的問題是“靜態資源”和“未處理的海量請求”。
1 先來看看靜態資源
秒殺活動的目的是促銷。為了控制成本，大型秒殺活動的頻次是很低的，有的商家可能一年只搞一兩次。
因此，為了一次備受矚目的秒殺，商家將做好充分準備：精心準備文案撰寫，精心設計高清圖片，為產品拍攝視訊剪輯……但是，這些靜態資源（如圖片和視訊）為系統帶來了負擔 。
在秒殺期間，這些靜態資源將被大量使用者訪問，這將導致網路頻寬瓶頸。因此，還必須考慮網路頻寬的負載能力。比如問題：怎樣儲存秒殺活動時的大量靜態資源？怎樣解決靜態資源造成的網路寬頻問題？
2 海量請求的處理
前臺是整個秒殺系統第一次面對大量需求。因此，在前臺遇到的請求數是“真實的”，尚未得到處理。並且在所有使用者請求中，除了正常請求之外，還可能存在各種無效或非法請求。
舉例如下： 可以看出，在整個秒殺活動期間，請求的實際數量要遠大於潛在的使用者數量。前臺頁面就是整個秒殺系統承受流量的第一道防線。
使用者在等待秒殺開始的前幾秒，可能會反覆重新整理頁面； 搶單機器人甚至可以執行毫秒級的輪詢來獲取訂單。
如何在前臺限流，盡力守衛後臺伺服器和資料庫伺服器？ 說明：本段文字以及本節的後續內容，在描述時使用了很多的疑問句，例如：“秒殺活動時如何儲存大量靜態資源？”。
後臺伺服器
即使在前臺進行了限流，也仍然會有大量合法請求湧到後臺伺服器。因此，後臺伺服器就需要解決高併發造成的各種問題，舉例如下。
資料的準確性。例如超賣問題、併發一致性問題等。
超賣問題。即如何避免“使用者成功下單的數量 > 秒殺商品的庫存數量”？在處理超賣時，還要考慮一些不良的惡意行為。例如，如果競爭對手故意將商品搶到手但卻不付款，該如何處理？
併發環境下的一致性問題。如果使用了快取，如何保證快取的一致性？如果使用了分散式，如何保證分散式事務的一致性？
資料的時效性。除了要在併發環境下保證資料的準確性以外，秒殺系統還要控制資料的時效性。例如，使用者在下單後，系統務必要在幾秒內返回結果，保證使用者體驗。
系統的可用性。為了防止單節點故障，保證系統的高可用性，就需要將秒殺系統部署在由多個節點組成的叢集上。叢集如何搭建？應該依據什麼將海量請求分流到叢集中的不同節點上？在機房部署叢集時，應該如何具體劃分？
系統的穩定性。除了高可用以外，我們也應當盡力提高叢集中各個節點的效能。高併發會導致部分節點的效能下降，甚至造成某些節點的崩潰。我們如何在有限的硬體條件下，提高單節點的效能，從而提高整個叢集系統的穩定性？
提示：以上描述的“系統的可用性”是指搭建叢集，“系統的穩定性”是指提高叢集中每個節點的效能。
作為系統的設計者，我們還應當思考：即使我們盡力準備了一切，但如果秒殺服務在極端情況下仍然無法滿足海量請求的衝擊，是否會對電商平臺中物流、客服等其它服務造成影響？即，秒殺服務只是整個電商系統中的一個子系統，我們應該在為秒殺服務做好充足準備的同時，再為整個系統留一條退路。
高併發問題一直是後端開發的難點之一，而秒殺又是高併發的極致體現。因此，秒殺系統的後端設計，也是後端開發者的最大挑戰之一。
資料庫伺服器
資料庫作為整個系統的儲存末端，是系統的最後一塊陣地。前臺沒了，可以重寫；後臺沒了，可以重造。
但如果資料庫垮了，資料就徹底沒了（暫不考慮資料恢復技術）。 你能想象銀行資料庫垮掉帶來的後果嗎？
在秒殺等高併發問題中，資料庫面對的核心問題是“併發量”、“併發訪問”和“儲存容量”。
1 併發量
對於一般的單節點關係型資料庫來說，僅僅能夠穩定的支撐千位數的併發量。因此在高併發環境中，往往最先遇到併發瓶頸的就是資料庫。
簡言之，資料庫是整個系統最重要的一環，但同時又是併發能力較弱的一層。
2 併發數
當海量請求經過了前臺和後臺的重重攔截抵達資料庫時，必然會產生併發問題。那麼，應該如何既避免併發帶來的問題，又能高效進行資料儲存呢？
3 儲存容量
一個關係型資料庫的儲存容量有限。對於大型電商平臺而言，是無法將全部的資料儲存到同一個資料庫中的。那麼，資料應該如何儲存？儲存後，如何保證資料庫的高可用？
小結
本節分析了秒殺活動給電商系統帶來的巨大挑戰。
系統的前臺，一方面會承受秒殺帶來的全部流量衝擊，另一方面需要對這些原始流量進行過濾，為後臺和資料庫減壓。
前臺過濾後的流量會抵達後臺伺服器，後臺作為整個系統的邏輯處理核心，既要保證請求資料的準確性、時效性，也要顧及系統的可用性和穩定性。
通過後臺處理的流量最終會衝向資料庫，資料庫要在自身併發數和儲存容量都較低的情況下，禦敵高併發量的衝擊。
綜上，秒殺系統的設計貫穿了前臺、後臺和資料庫等各個層面設計，並且對每個層面都擁有極限的考驗。因此，對秒殺系統的設計也是全棧開發者面對的一個考驗
本作品採用《CC 協議》，轉載必須註明作者和本文連結