如何設計一個秒殺系統----學習總結
第一章學習總結——概覽https://time.geekbang.org/column/article/40153
1.秒殺主要解決問題——並發讀和並發寫。並發讀的核心優化理念是盡量減少用戶到服務端來讀取數據，或者讓他們讀更少的數據。並發寫的處理原則是在數據庫層面獨立出一個庫，做特殊的處理。另外針對秒殺系統做一些保護，針對意料之外的情況設計兜底方案，以防止最壞的情況發生。
2.從一個架構師的角度來看，要想打造並維護一個超大流量並發讀寫、高性能、高可用的系統，在整個用戶請求路徑上從瀏覽器到服務端我們要遵循幾個原則，就是要保證用戶請求的數據盡量少、請求數盡量少、路徑盡量短、依賴盡量少，並且不要有單點。
3.秒殺的整體架構可以概括為“穩、準、快”（高可用、一致性、高性能）幾個關鍵字。
所謂“穩”，就是整個系統架構要滿足高可用，流量符合預期時肯定要穩定，就是超出預期時也同樣不能掉鏈子，你要保證秒殺活動順利完成，即秒殺商品順利地賣出去，這個是最基本的前提。
“準”，就是秒殺 10 臺 iPhone，那就只能成交 10 臺，多一臺少一臺都不行。一旦庫存不對，那平臺就要承擔損失，所以“準”就是要求保證數據的一致性。
“快”，“快”其實很好理解，它就是說系統的性能要足夠高，否則你怎麽支撐這麽大的流量呢？不光是服務端要做極致的性能優化，而且在整個請求鏈路上都要做協同的優化，每個地方快一點，整個系統就完美了。
所以從技術角度上看“穩、準、快”，就對應了我們架構上的高可用、一致性和高性能的要求。
高性能：
秒殺涉及大量的並發讀和並發寫，因此支持高並發訪問這點非常關鍵。主要包含數據的動靜分離方案、熱點的發現與隔離、請求的削峰與分層過濾、服務端的極致優化這 4 個方面。
一致性：
秒殺中商品減庫存的實現方式同樣關鍵。有限數量的商品在同一時刻被很多倍的請求同時來減庫存，減庫存又分為“拍下減庫存”“付款減庫存”以及預扣等幾種，在大並發更新的過程中都要保證數據的準確性。
高可用：
現實中總難免出現一些考慮不到的情況，所以要保證系統的高可用和正確性，還要設計一個 PlanB 來兜底，以便在最壞情況發生時仍然能夠從容應對。
——————————————————————————————————————————————————————————————————————————————————
第二章學習總結——設計秒殺系統應該註意的五個（4要1不要）架構原則。https://time.geekbang.org/column/article/40726
1.數據量盡量少：請求數據和返回數據都要盡量少，以減少CPU使用。
2.請求數要盡量少：減少額外請求，如合並js、css等，首屏HTML內聯所需的CSS、JS。
3.路徑要盡量短：減少節點數，相互強依賴的應用合並部署。節點越少出錯概率就越小，可用性就越高。所以縮短請求路徑不僅可以增加可用性，同樣可以有效提升性能（減少中間節點可以減少數據的序列化與反序列化），並減少延時（可以減少網絡傳輸耗時）。
4.強依賴盡量少：給數據重要性分等級，盡量減少所要加載的數據。
5.不要有單點，要有備份，如設計分布式系統，關鍵點是把服務無狀態話，避免將服務的狀態和機器綁定，使服務可以在機器中隨意移動。
架構是一種平衡的藝術，而最好的架構一旦脫離了它所適應的場景，一切都將是空談。所以設計架構時上面幾點只是方向，應該根據實際情況適當取舍。
補充：
答疑：
1 .本地cache用什麽實現好呢？
本地cache一般就是用內存實現，如java用集合類型就行
- 通過什麽方式往本地cache 寫數據呢？
用訂閱的方式，在初始化時加載到內存 - 秒殺系統的及時性非常高，把庫存寫進cache ，怎麽及時更新呢？
有兩種方法，一是定時更新取3秒，二是，主動更新，數據庫字段更新後發消息更新緩存，這個需要用到一個組件阿裏叫metaq就是就是數據庫字段更新會產生一條消息。另外cache裏庫存不需要100%和數據庫一致，最終強一致性即可
4.各QPS級別架構可能瓶頸點？
不同QPS量級下瓶頸也會不一樣，10w級別可能瓶頸就在數據讀取上，通過增加緩存一般就能解決，如果要到100w那麽，可能服務端的網絡都是瓶頸，所以要把大部分的靜態數據放到cdn上甚至緩存在瀏覽器裏。
5.單點是什麽？
單點就是一個狀態值存儲在一臺機器上，這臺機器掛了，這個狀態就丟了，導致整個服務不可用。最常用的就是本機存儲數據，而這個數據沒有備份的情況
架構示例：
1-10萬QPS級別架構設計示例圖：
如何設計一個秒殺系統----學習總結