一.什麽樣的數據適合緩存

二.緩存策略一些問題應對總結

　　(1).緩存穿透

　　　　緩存穿透是指查詢一個一定不存在的數據，由於緩存是不命中時需要從數據庫查詢，查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到數據庫去查詢，造成緩存穿透。在流量大時，可能DB就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。

　　應對方案：

1. 如果對應在數據庫中的數據都不存在，我們將此key對應的value設置為一個默認的值，比如“NULL”，並設置一個緩存的失效時間。當然這個key的時效比正常的時效要小的多
2. 采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層數據庫的查詢壓力。

　　(2).緩存雪崩

　　　　緩存雪崩是指在設置緩存時采用了相同的過期時間，導致緩存在某一時刻同時失效，導致所有的查詢都落在數據庫上，造成了緩存雪崩。

　　　應對方案：

　　　　1.將系統中key的緩存失效時間均勻地錯開，防止統一時間點有大量的key對應的緩存失效。比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個緩存的過期時間的重復率就會降低，就很難引發集體失效的事件。

　　　　2.建立備份緩存，緩存A和緩存B，A設置超時時間，B不設值超時時間，先從A讀緩存，A沒有讀B，並且更新A緩存和B緩存。

　　　　3.在固定的緩存時間上加上隨機時間長度，比如固定緩存5分鐘加上隨機的1到3分鐘不等，在一定程度上可以避免緩存雪崩。

　　(3).緩存擊穿

　　　　對於一些設置了過期時間的key，如果這些key可能會在某些時間點被超高並發地訪問，是一種非常“熱點”的數據。這個時候，需要考慮一個問題：緩存被“擊穿”的問題，這個和緩存雪崩的區別在於這裏針對某一key緩存，前者則是很多key。
緩存在某個時間點過期的時候，恰好在這個時間點對這個Key有大量的並發請求過來，這些請求發現緩存過期一般都會從後端DB加載數據並回設到緩存，這個時候大並發的請求可能會瞬間把後端DB壓垮。

　　　應對方案：

　　　　1.雙緩存策略

　　　　2.緩存永遠不過期

　　　　　　這裏的“永遠不過期”包含兩層意思：

　　　　　　 (1) 從緩存上看，確實沒有設置過期時間，這就保證了，不會出現熱點key過期問題，也就是“物理”不過期。

　　　　　　 (2) 從功能上看，如果不過期，那不就成靜態的了嗎？所以我們把過期時間存在key對應的value裏，如果發現要過期了，通過一個後臺的異步線程進行緩存的構建，也就是“邏輯”過期.

redis 緩存策略註意的問題總結