首頁 > 軟體

淺談Redis快取雪崩解決方案

2022-05-18 13:03:40

快取層承載著大量的請求,有效保護了儲存層。但是如果由於大量快取失效或者快取整體不能提供服務,導致大量的請求到達儲存層,會使儲存層負載增加(大量的請求查詢資料庫) 。這就是快取雪崩的場景;

解決快取雪崩可以從下面的幾點著手:

1.保持快取層的高可用

使用Redis哨兵模式或者Redis叢集部署方式,即是個別Redis節點下線,整個快取層依然可以使用。除此之外還可以在多個機房部署Redis,這樣即便是機房宕機,依然可以實現快取層的高可用。

2.限流降級元件

無論是快取層還是儲存層都會有出錯的概率,可以將它們視為資源。作為並行量較大的分散式系統,假如有一個資源不可用,可能會造成所有執行緒在獲取這個資源時異常,造成整個系統不可用。降級在高並行系統中是非常正常的,比如推薦服務中,如果個性化推薦服務不可用,可以降級補充熱點資料,不至於造成整個推薦服務不可用。常見的限流降級元件如 Hystrix、Sentinel 等。

3.快取不過期

Redis 中儲存的 key 永不失效,這樣就不會出現大量快取同時失效的問題,但是隨之而來的就是Redis 需要更多的儲存空間。

4.優化快取過期時間

設計快取時,為每一個 key 選擇合適的過期時間,避免大量的 key 在同一時刻同時失效,造成快取雪崩。

5.使用互斥鎖重建快取

在高並行場景下,為了避免大量的請求同時到達儲存層查詢資料、重建快取,可以使用互斥鎖控制,如根據 key 去快取層查詢資料,當快取層為命中時,對 key 加鎖,然後從儲存層查詢資料,將資料寫入快取層,最後釋放鎖。若其他執行緒發現獲取鎖失敗,則讓執行緒休眠一段時間後重試。對於鎖的型別,如果是在單機環境下可以使用 Java 並行包下的 Lock,如果是在分散式環境下,可以使用分散式鎖(Redis 中的 SETNX 方法)。

分散式環境下互斥鎖重建快取虛擬碼

/**
 * 互斥鎖建立快取
 *
 **/
public String get(String key) {
   // redis中查詢key對應的value
   String value = redis.get(key);
   // 快取未命中
   if (value == null) {
      // 互斥鎖
      String key_mutex_lock = "mutex:lock" + key; 
      // 互斥鎖加鎖成功
      if(redis.setnx(key_mutex_lock,"1")) { // 返回 0(false),1(true)
          try {
              // 設定互斥鎖超時時間,這裡設定的是鎖的失效時間,而不是key的失效時間
              redis.expire(key_mutex_lock,3*60);
              // 從資料庫查詢
              value = db.get(key);
              // 資料寫入快取
              redis.set(key,value);
            
          } finally {
               // 釋放鎖
              boolean keyExist = jedis.exists(key_mutex_lock);
              if(keyExist){
                  redis.delete(key_mutex_lock);
               }
      } else { 
              // 加鎖失敗,執行緒休息50ms後重試
               Thread.sleep(50);
               return get(key); // 直接返回快取結果  
     }
   }
}

分散式環境下使用Redis 分散式鎖實現快取重建,優點是設計思路簡單,對資料一致性有保障;缺點是程式碼複雜度增加,有可能會造成使用者等待。假設在高並行下,快取重建期間 key 是鎖著的,如果當前並行 1000 個請求,其中 999 個都在阻塞,會導致 999 個使用者請求阻塞而等待。

6.非同步重建快取

在這種方案下構建快取採取非同步策略,會從執行緒池中獲取執行緒來非同步構建快取,從而不會讓所有的請求直接到達儲存層,該方案中每個Redis key 維護邏輯超時時間,當邏輯超時時間小於當前時間時,則說明當前快取已經失效,應當進行快取更新,否則說明當前快取未失效,直接返回快取中的 value 值。如在Redis 中將 key 的過期時間設定為 60 min,在對應的 value 中設定邏輯過期時間為 30 min。這樣當 key 到了 30 min 的邏輯過期時間,就可以非同步更新這個 key 的快取,但是在更新快取的這段時間內,舊的快取依然可用。這種非同步重建快取的方式可以有效避免大量的 key 同時失效。

/**
  *  非同步重建快取: ValueObject為對應的封裝的實體模型
  *
  **/
public String get(String key) {
    // 重快取中查詢key對應的ValueObject物件
    ValueObject valueObject = redis.get(key);
    // 獲取儲存中對應的value值
    String value = valueObject.getValue();
    // 獲取實體模型中的快取過期的時間:timeOut = 設定快取時的當前時間+過期時間(如30秒,60秒等等)
    long logicTimeOut = valueObject.getTimeOut();  // 等位換算為long型別
    // 當前可以在邏輯上失效
    if (logicTimeOut <= System.currentTimeMillis()) {
         // 非同步更新快取
         threadPool.execute(new Runnable() {
             String key_mutex_lock = "mutex_lock" + key;
              // 互斥鎖加鎖成功
      if(redis.setnx(key_mutex_lock,"1")) { // 返回 0(false),1(true)
          try {
              // 設定互斥鎖超時時間,這裡設定的是鎖的失效時間,而不是key的失效時間
              redis.expire(key_mutex_lock,3*60);
              // 從資料庫查詢
              dbValue = db.get(key);
              // 資料寫入快取
              redis.set(key,dbValue);
            
          } finally {
              // 釋放鎖
              boolean keyExist = jedis.exists(key_mutex_lock);
              if(keyExist){
                  redis.delete(key_mutex_lock);
               }
             
         }
      } else { 
             
              
             }
             
         
         });
       return value; // 直接返回快取結果  
    }
}

到此這篇關於淺談Redis快取雪崩解決方案的文章就介紹到這了,更多相關Redis快取雪崩內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!


IT145.com E-mail:sddin#qq.com