遵循的原則：保證使用者請求的資料盡量少、請求數盡量少、路徑盡量短、依賴盡量少，並且不要有單點。
高效能。 秒殺涉及大量的併發讀和併發寫，因此支援高併發訪問這點非常關鍵。本專欄將從設計資料的動靜分離方案、熱點的發現與隔離、請求的削峰與分層過濾、服務端的極致優化這 4 個方面重點介紹。
一致性。 秒殺中商品減庫存的實現方式同樣關鍵。可想而知，有限數量的商品在同一時刻被很多倍的請求同時來減庫存，減庫存又分為「拍下減庫存」「付款減庫存」以及預扣等幾種，在大併發更新的過程中都要保證資料的準確性，其難度可想而知。因此，我將用一篇文章來專門講解如何設計秒殺減庫存方案。
高可用。 雖然我介紹了很多極致的優化思路，但現實中總難免出現一些我們考慮不到的情況，所以要保證系統的高可用和正確性，我們還要設計乙個 planb 來兜底，以便在最壞情況發生時仍然能夠從容應對。專欄的最後，我將帶你思考可以從哪些環節來設計兜底方案。
請求數盡量少
路徑盡量短
依賴盡量少
不要有單點
如何設計乙個秒殺系統
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...
如何設計乙個秒殺系統
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...
如何設計乙個秒殺系統
秒殺一般是訪問請求數量遠遠大於庫存數量，只有少部分使用者能夠秒殺成功。秒殺業務流程比較簡單，一般就是下訂單減庫存。瀏覽器端 js 服務端控制器層 閘道器層 服務層利用快取應對讀請求 對類似於12306等購票業務，是典型的讀多寫少業務，大部分請求是查詢請求，所以可以利用快取分擔資料庫壓力。利用快取應對...