最近總有一些朋友問高併發問題，後來就想自己把一個秒殺系統作爲例子詳細分解一下，也是一個學習過程。
首先假設場景，預計該活動可能有1萬人參加，那最大併發數爲1萬。
主要面對的問題分析：
1.對原有業務的影響，秒殺類活動肯定屬於附加的業務，如果和原有業務部署在一起，那就會對原有業務造成衝擊。注意：哪怕和原有業務不部署在一起也會對原有的相關業務（接口、入口、出口等）產生一定的衝擊。
2.高併發下的服務、數據庫負載問題
3.帶寬問題
4.直接下單問題（越過商品選擇直接訪問下單url）
解決方案
1.秒殺系統獨立部署
2.秒殺商品頁面靜態化，必要的動態數據緩存處理
3.購買/租用臨時帶寬
4.動態生成隨機下單頁面URL
架構設計
1.分析用戶心理，用戶關心的刷新速度、快速下單，而不是複雜詳細的商品詳情。控制購買按鈕在開始前不可用，準點變爲可用。下單頁面也應該儘可能的簡潔，甚至可以不寫地址直接付款下單，然後再修改地址（可選）。
2.秒殺按鈕如何控制，因爲商品頁面靜態化了並且做了cdn，如果通過接口控制對服務器壓力會很大，所以可以選用前端js控制。在商品頁面引入一個js文件，這個文件不被緩存和cdn，使用隨機版本號。這個js文件包括活動是否開始的標記和隨機下單的url參數。通過定時間來在活動開始的時間更新這個js文件
3.控制訂單，兩級控制，限制每臺服務器接受訂單數，驗證總的訂單數。
4.基本架構，商品服務器集羣，CDN，JS服務器集羣，訂單服務器集羣，定時服務器，全局計數器（memcache、redis等）、訂單處理子系統（用來處理訂單成功的後續邏輯）