快取粒度控制

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

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

快取穿透問題

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

可能造成原因：

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

危害:

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

解決方案 :

1.快取空物件

public class NullValueResultDO implements Serializable{
private static final long serialVersionUID = ‐6550539547145486005L;
}
public class UserManager {
UserDAO userDAO;
LocalCache localCache;
public UserDO getUser(String userNick) {
Object object = localCache.get(userNick);
if(object != null) {
if(object instanceof NullValueResultDO) {
return null;
}
return (UserDO)object;
} else {
User user = userDAO.getUser(userNick);
if(user != null) {
localCache.put(userNick,user);
} else {
localCache.put(userNick, new NullValueResultDO());
}
return user;
}
}
}

2.布隆過濾器

快取擊穿.熱點key重建快取問題

快取擊穿是指快取中沒有但資料庫中有的資料（一般是快取時間到期），這時由於併發使用者特別多，同時讀快取沒 讀到資料，又同時去資料庫去取資料，引起資料庫壓力瞬間增大，造成過大壓力 我們知道，使用快取，如果獲取不到，才會去資料庫裡獲取。但是如果是熱點 key，訪問量非常的大，資料庫在重 建快取的時候，會出現很多執行緒同時重建的情況。因為高併發導致的大量熱點的 key 在重建還沒完成的時候，不斷 被重建快取的過程，由於大量執行緒都去做重建快取工作，導致伺服器拖慢的情況。

解決方案

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

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

快取雪崩問題

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

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

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

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

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