這種題目，小菜是準備過的，巴拉巴拉的說了一堆。
面試官：那這裡是怎麼保證秒殺成功的？
小菜：&8^%#
面試官：你這裡用了redis，有什麼用？
小菜：#￥&……%
面試官：你用什麼測試過這個系統的併發量？
小菜：&*%$^&.
面試官：你覺得你這個系統還可以再優化麼？
小菜：&%……￥）
面試官：你知道這個系統的瓶頸在**嗎？如果流量再大10倍，怎麼應對？
小菜：88！
秒殺系統的整體架構可以概括為「穩、準、快」幾個關鍵字。
所謂「穩」，就是整個系統架構要滿足高可用，流量符合預期時肯定要穩定，超出預期時也同樣不能掉鍊子，你要保證秒殺活動順利完成，即秒殺商品順利地賣出去，這個是最基本的前提。
然後就是「準」，你的業務需求是秒殺10臺iphone xs，那就只能成交10臺，多一台少一台都不行。一旦庫存不對，那平台就要承擔損失，所以「準」就是要求保證資料的一致性。
最後再看「快」，「快」其實很好理解，它就是說系統的效能要足夠高，否則你怎麼支撐這麼大的流量呢？不光是服務端要做極致的效能優化，而且在整個請求鏈路上都要做協同的優化，每個地方快一點，整個系統就完美了。
所以，一般優化設計思路：將請求攔截在系統上游，降低下游壓力。
在乙個併發量大，實際需求小的系統中，應當盡量在前端攔截無效流量，降低下游伺服器和資料庫的壓力，不然很可能造成資料庫讀寫鎖衝突，甚至導致死鎖，最終請求超時。
限流：前端直接限流，允許少部分流量流向後端。
削峰：瞬時大流量峰值容易壓垮系統，解決這個問題是重中之重。常用的消峰方法有非同步處理、快取和訊息中介軟體等技術。
非同步處理：秒殺系統是乙個高併發系統，採用非同步處理模式可以極大地提高系統併發量，其實非同步處理就是削峰的一種實現方式。
記憶體快取：秒殺系統最大的瓶頸一般都是資料庫讀寫，由於資料庫讀寫屬於磁碟io，效能很低，如果能夠把部分資料或業務邏輯轉移到記憶體快取，效率會有極大地提公升。
訊息佇列：訊息佇列可以削峰，將攔截大量併發請求，這也是乙個非同步處理過程，後台業務根據自己的處理能力，從訊息佇列中主動的拉取請求訊息進行業務處理。
可拓展：當然如果我們想支援更多使用者，更大的併發，最好就將系統設計成彈性可拓展的，如果流量來了，拓展機器就好了，像**、京東等雙十一活動時會臨時增加大量機器應對交易高峰。
高併發秒殺系統方案（簡介）
memcatch相比redis而言，無法做持久化。jsr303 服務端的驗證框架。首先我們可以將靜態頁面快取在使用者的瀏覽器端或者是手機端，然後使用者的請求會到達cdn 的快取和映象 進一步到達閘道器 我們這裡是nginx，在nginx上繼續做快取 再到我們的應用伺服器 同樣可以做快取 redis快...
高併發秒殺系統思路 佇列
今天看了篇大佬的文章,乙個比較基礎的高併發的 跟以前學習是看到的生產者消費者的模式差不多,後來想了下,高併發的場景下用佇列來做應該才是最優解 個人拙見 於是又到處搜了下關於使用佇列的相關 思路上簡單來說,就是在請求的時候,將這個請求的物件加入佇列內,然後在多執行緒的處理方法內,從佇列裡pop出來執行...
高併發下商城秒殺活動的處理
秒殺搶購活動是現在很多 常見的營銷手段，小公尺搶購 的整點免單 聚划算等都是成功的例子。從簡單處著手，秒殺是很好理解的 設定要秒殺的商品的數量，搶完為止。但是，實際應用中一瞬間的高併發壓力 以及併發帶來的負庫存是要著重考慮。要避免負庫存的出現，可以在資料庫加鎖，不管外部多少請求，都可以在資料庫操作前...