記錄：今天發生一起嚴重線上事故 資料庫崩潰導致服務不可用。排查時發現10：16左右資料庫達到6700qps。
檢查後發現：運營配置了活動10：17的秒殺活動。導致流量倍增。本身這裡是用了快取的。3分鐘的快取。在快取失效後
第乙個請求的結果沒有寫入到redis之前。這段時間的6000+請求量全部湧入到資料庫.導致資料庫癱瘓。
解決方案（個人，可能會有遺漏）：
1：本次活動時前n名免單，使用者一直重新整理商品頁面，實際上對庫存要求不時很高。主要原因就是平凡重新整理的問題。
可以寫定時任務，在快取失效前一段時間，查詢一次快取 更新到redis中。 比如 3分鐘的快取，可以在更新快取時，觸發乙個定時任務：這個定時任務在2分30秒後查詢資料庫，手動更新快取。這樣快取可以永遠不失效，永遠命中快取。
2：如果是真正的有限庫存的秒殺型別，可以讓秒殺高峰期，快取永不失效。訂單通過佇列來處理，處理前插敘快取庫存是否為0.每個訂單扣減庫存都放在快取裡做，絕不去查詢資料庫。當快取為0時 拒絕訂單，並且修改資料庫庫存。 這樣做對資料庫完全沒什麼壓力。壓力主要在介面上。就可以通過nginx**，非同步佇列和多加服務節點來解決。
redis快取擊穿
1 快取擊穿出現的場景 我們知道redis的資料是儲存在記憶體的，而記憶體是有限的，所以一般會設定過期時間，當某個key過期了，而此時大量的併發來請求這個key，導致都去請求mysql啦，而mysql的併發連線數很低，缺少了redis這層盾牌，mysql自然扛不住，這不是架構的問題，因為之前的架構中...
Redis快取擊穿
什麼是快取擊穿 key對應的資料存在，但是在redis中key過期了，此時如有大量的併發請求過來，這些請求發現快取過期一般都會從後端伺服器載入資料並回設到快取，這個時候大併發請求可能會瞬間把後端db壓垮 如圖 出現快取穿透的特點 1.資料庫訪問壓力瞬間增加 2.redis裡面出現大量key過期 3....
redis 快取擊穿 3
在談論快取擊穿之前，我們先來回憶下從快取中載入資料的邏輯，如下圖所示 因此，如果黑客每次故意查詢乙個在快取內必然不存在的資料，導致每次請求都要去儲存層去查詢，這樣快取就失去了意義。如果在大流量下資料庫可能掛掉。這就是快取擊穿。場景如下圖所示 我們正常人在登入首頁的時候，都是根據userid來命中資料...