就拿我熟悉的**來說。當你訪問**時，前端需要渲染頁面，所以要從後端獲取到資料。資料**來？當然是資料庫（關聯式資料庫或者非關聯式資料庫）中。
關係型資料庫：mysql
非關係型資料庫：redis
而mysql一般相對於redis讀寫效能較差，所以採用redis來儲存資料，而不是直接請求mysql。
當後端接到前端的資料請求，如果redis中有資料快取，直接拿快取資料，返回給前端
當redis中的快取失效，先請求mysql，將資料快取至redis中。再查詢redis獲取資料
避免造成大量請求打入mysql中，導致伺服器崩潰
大量redis資料快取在一瞬間（由於設定了過期時間）全部失效，導致所有請求全部直接請求資料庫，造成資料庫壓力太大而雪崩，無法再對外提供服務。
解決方案：
1.設定快取的失效時間，隨機初始化失效時間，不會讓所有的redis快取在同一時間失效。
2.對於集群分布的redis，將熱點的key設定在不同的redis節點上
3.設定定時任務，在快取失效前請求資料庫的資料。
4.限流和降級，提前預估系統處理能力
5.對大的熱 key， 直接快取在本地
由於資料庫主鍵從0開始，沒有負數。惡意使用者 利用id小於0的引數發請求，redis查不到id小於0的資料，就去資料庫中查。直接穿透進資料庫中
解決方案：
1.如果資料庫中無法查到結果，也返回給redis，對應的值為空。這樣下次同樣id小於0的引數請求，不會再請求資料庫，而是從redis中拿到空資料。無法穿透redis
2.ip拉黑
3.引數校驗（最重要）
4.布隆過濾器
基本和快取雪崩相同，不同的是，快取擊穿指併發查同一條熱點資料，而快取雪崩指的是大量資料同時失效
解決方案：
1.快取永不過期，但是你覺得好嘛？
2.分布式鎖。單體應用則採用互斥鎖
（具體分析：如果redis資料為空，請求資料庫資料，在請求資料庫這一步，給執行緒加鎖，這樣就只有乙個執行緒能搶到鎖，只有乙個執行緒能運算元據庫，壓力小，當查詢完畢，將資料快取至redis中，沒有搶到鎖的執行緒先睡幾秒，然後再次去redis拿資料）
1.專案上線前，（資金足夠）採用分布式集群，無論是web伺服器，還是redis伺服器，資料庫伺服器。保證服務高可用性
2.專案執行中。及時採取限流措施，手動調整。比如臨時租個redis，模擬請求，將資料暫時快取起來，而不是任由資料直接請求資料庫，造成資料庫宕機，甚至毀壞
redis rdb機制，aof持久化機制，快速恢復
Redis快取穿透,穿透擊穿,快取雪崩
乙個一定不存在快取及查詢不到的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。有很多種方法可以有效地解決快取穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bit...
redis 快取穿透 擊穿 雪崩
介面層增加校驗，如使用者鑑權校驗，id做基礎校驗，id 0的直接攔截 從快取取不到的資料，在資料庫中也沒有取到，這時也可以將key value對寫為key null，快取有效時間可以設定短點，如30秒 設定太長會導致正常情況也沒法使用 這樣可以防止攻擊使用者反覆用同乙個id暴力攻擊 public o...
redis快取穿透，擊穿，雪崩
快取穿透 描述 快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷發起請求，多來自於黑客攻擊。由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。在流量大時，可能db就掛掉了，要是有人利用不存在的k...