**1、秒殺還沒開始頁面就崩了** 比如12306 2010年夏天上線的 當時只是針對北京地區開放 剛開始一切正常 但是到了11年春運 還沒到放票前頁面就打不開了 這是一個秒殺前崩潰的典型案例 **一般我們的優化手段有頁面靜態化 cdn等等** **2、秒殺剛開始服務器就崩潰了** 在12306的早期連數據庫的讀寫分離都沒有做，放票時間一到就有好多人開始搶票 點了搶票什么反應也沒有 重啟服務器也沒用 服務器起來之后瞬間又崩潰了** 針對這種情況我們一般采用限流、令牌等技術來解決瞬時高峰的問題，比如說一列火車有1000個座位但是有1萬個人來搶，我們可以準備2000個令牌，只有拿到令牌的人才有資格搶票，其他的8000個人就被擋到外面了，告訴這8000個人已經沒票了，這樣可以快速的給用戶相應**。 **3、秒殺結束后，庫存崩了 即庫存超賣了** 解決超賣一般就是加分布式鎖，**通過分布式鎖來保證庫存不超賣** **4、秒殺過程沒問題，但是服務器響應很慢** 一般加上分布式鎖會影響性能，所以我們為了提高給用戶的相應速度，**會使用異步消峰+排隊機制**在保證庫存不超賣的同時還能保證給這進來的2000個用戶快速的相應 ###