淺談Redis中的緩存更新策略


1. 緩存更新策略綜述
- 內存淘汰
- 不用自己維護,利用 Redis 自己的內存淘汰機制 (內存不足時,觸發(fā)策略,默認開啟,可自己配置),其可在一定程度上保持數(shù)據一致性
- 超時剔除
- 給數(shù)據添加 TTL,到期之后自動剔除,是最終一致性
- 自動更新
- 編寫業(yè)務邏輯,修改數(shù)據庫時,更新緩存,一致性高,維護成本高
2. 緩存策略的選擇
選擇內存策略,要基于業(yè)務場景 —— 低一致性需求,高一致性需求

3. 主動更新策略
緩存的主動更新策略又分為以下三種:

4. Cache Aside Pattern
Cache Aside Patter 是我們比較常用的緩存更新策略,其由緩存調用者在更新數(shù)據庫時,在業(yè)務邏輯中設置緩存更新。對 Cache Aside Pattern ,有以下三個問題比較重要。
- 是刪除緩存還是更新緩存?
使用更新數(shù)據庫時刪除緩存,下次讀數(shù)據的時候再寫入緩存的策略,更新緩存會產生很多不必要的寫操作。 - 如何保證緩存與數(shù)據庫的操作的同時成功或者失敗
在單體項目中很好控制,在分布式項目中,使用分布式事務解決。 - 先操作緩存還是先操作數(shù)據庫
線程問題:使用先操作數(shù)據庫,再刪除緩存。先操作數(shù)據庫再操作緩存,能減少發(fā)生問題的概率。
如下是兩種線程不安全問題產生的場景,但是因為緩存的操作數(shù)據的速度是遠遠高于數(shù)據庫寫操作的速度的,因此先操作數(shù)據庫再刪除緩存,出現(xiàn)問題的可能性低。

5.代碼實現(xiàn)
在更新代碼中,加入刪除緩存的邏輯即可,代碼示例如下:
@Override
public Result update(Shop shop) {
if(shop == null){
return Result.fail("店鋪不能為 null");
}
// 更新數(shù)據庫
updateById(shop);
// 刪除緩存
stringRedisTemplate.delete(CACHE_SHOP_KEY + shop.getId());
return Result.ok();
}到此這篇關于淺談Redis中的緩存更新策略的文章就介紹到這了,更多相關Redis緩存更新策略內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
Redis過期事件監(jiān)聽器的完整實現(xiàn)步驟
要使用 Redis 過期事件監(jiān)聽器來更新數(shù)據庫狀態(tài),我們需要確保 Redis 的事件通知已啟用,并實現(xiàn)監(jiān)聽器來捕獲過期的鍵,并根據需要更新數(shù)據庫,本文給大家介紹了Redis過期事件監(jiān)聽器的完整實現(xiàn)步驟,需要的朋友可以參考下2024-10-10
Redis數(shù)據庫的使用場景介紹(避免誤用Redis)
這篇文章主要介紹了Redis數(shù)據庫的使用場景介紹(避免誤用Redis),本文用簡要的語言總結了Redis數(shù)據庫的適應場合,人而避免錯誤的使用它而產生昂貴的維護代價,需要的朋友可以參考下2015-03-03

