隨著電商的發展，秒殺系統已經發展成為電商必不可少的組成部分，如小公尺手機的秒殺，12306的搶票，這些系統的共同特點都是：庫存只有乙份，瞬時流量非常大，所有人會在集中的時間讀和寫這些資料，多個人讀乙個資料；讀寫衝突，鎖非常嚴重，這是秒殺業務難的地方。那我們怎麼構建秒殺業務的架構呢？
構建架構需要總體做到兩點：
1、請求盡量攔截在系統上游；2、使用快取抗讀壓力
做限速，禁止使用者重複提交，限制使用者幾秒內只允許訪問一次
站點控制層
：必須進行登入有uid才能操作，對uid進行請求計數和去重，頁面快取，同乙個uid，限制訪問頻度，做頁面快取，x秒內到達站點層的請求，均返回同一頁面。同乙個item的查詢，例如車次，做頁面快取，x秒內到達站點層的請求，均返回同一頁面。如此限流，既能保證使用者有良好的使用者體驗（沒有返回404）又能保證系統的健壯性
服務層：
按照業務做寫請求佇列控制流量，做資料快取
資料庫層
：瀏覽器層，站點層攔截了並做了頁面快取，服務層又做了寫請求佇列與資料快取，每次透到資料庫層的請求都是可控的。db基本就沒什麼壓力了
對於秒殺系統還需要注意和考慮垂直拆分的分流以及回倉操作
秒殺系統優化思路
一 秒殺業務為什麼這麼難做 秒殺系統，庫存只有乙份，所有人會在集中的時間讀和寫這些資料。例如 那我們怎麼優化秒殺業務呢？二 優化方向 以上的兩個場景要優化有兩個方向 三 常見秒殺架構 常見的秒殺架構基本是這樣的 四 各層優化細節 回顧一下我們12306剛出來那年搶票的場景，點選 查詢 按鈕之後，系統...
秒殺系統架構優化思路
在 京東等電商類平台面試中，容易碰到乙個很常見的場景題 秒殺場景。本渣作者不敢瞎寫，附上兩篇 標準答案 希望小夥伴們可以從中學習到東西，也祝面試順利。本渣認為，類似問題有幾個考點 全域性思考能力和把控能力，包括從前端 網路 閘道器 後端 儲存等一整個資訊傳輸互動線路都有優化的點。架構設計原則 有效控...
秒殺系統架構優化思路
摘要 秒殺系統架構優化思路 上週參加qcon，有個兄弟分享秒殺系統的優化，其觀點有些贊同，大部分觀點卻並不同意，結合自己的經驗，談談自己的一些看法。一 為什麼難 秒殺系統難做的原因 庫存只有乙份，所有人會在集中的時間讀和寫這些資料。例如小公尺手機每週二的秒殺，可能手機只有1萬部，但瞬時進入的流量可能...