Redis快取三大問題解析

通俗來講，快取粒度問題就是我們在使用快取時，是將所有資料快取還是快取部分資料？

快取粒度問題是乙個容易被忽視的問題，如果使用不當，可能會造成很多無用空間的浪費，可能會造成網路頻寬的浪費，可能會造成**通用性較差等情況，必須學會綜合資料通用性、空間占用比、**維護性三點評估取捨因素權衡使用。

快取穿透是指查詢乙個一定不存在的資料，由於快取不命中，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。

1.業務**自身問題 2.惡意攻擊。爬蟲等等

對底層資料來源壓力過大，有些底層資料來源不具備高併發性。例如mysql一般來說單台能夠扛1000-qps就已經很不錯了

1.快取空物件

public class nullvalueresultdo implements serializable
public class usermanager 
return (userdo)object;
} else else 
return user;
}}          
}

2.布隆過濾器

快取擊穿是指快取中沒有但資料庫中有的資料（一般是快取時間到期），這時由於併發使用者特別多，同時讀快取沒讀到資料，又同時去資料庫去取資料，引起資料庫壓力瞬間增大，造成過大壓力

我們知道，使用快取，如果獲取不到，才會去資料庫裡獲取。但是如果是熱點 key，訪問量非常的大，資料庫在重建快取的時候，會出現很多執行緒同時重建的情況。因為高併發導致的大量熱點的 key 在重建還沒完成的時候，不斷被重建快取的過程，由於大量執行緒都去做重建快取工作，導致伺服器拖慢的情況。

1.互斥鎖

第一次獲取快取的時候，加乙個鎖，然後查詢資料庫，接著是重建快取。這個時候，另外乙個請求又過來獲取快取，發現有個鎖，這個時候就去等待，之後都是一次等待的過程，直到重建完成以後，鎖解除後再次獲取快取命中。

public string getkey(string key)else
} return value;
}

互斥鎖的優點是思路非常簡單，具有一致性，但是互斥鎖也有一定的問題，就是大量執行緒在等待的問題。存在死鎖的可能性。

快取雪崩是指機器宕機或在我們設定快取時採用了相同的過期時間，導致快取在某一時刻同時失效，請求全部**到db，db瞬時壓力過重雪崩。

1：在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。

2：做二級快取，a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期

3：不同的key，設定不同的過期時間，讓快取失效的時間點盡量均勻。

4：如果快取資料庫是分布式部署，將熱點資料均勻分布在不同的快取資料庫中。