本文實例為大家分享了Redis緩存更新策略的具體代碼，供大家參考，具體內容如下

一、緩存的收益與成本

1.1 收益

• 加速讀寫：因為緩存通常都是全內存的（例如Redis、Memcache），而存儲層通常讀寫性能不夠強悍（例如MySQL），內存讀寫的速度遠遠高于磁盤I/O。通過緩存的使用可以有效地加速讀寫，優化用戶體驗。
• 降低后端負載：幫助后端減少訪問量（Mysql設置有最大連接數，如果大量的訪問同時達到數據庫，而磁盤I/O的速度又很慢，很容易造成最大連接數被使用完，但Redis 理論最大）和復雜計算（例如很復雜的SQL語句），在很大程度降低了后端的負載。

1.2 成本

• 數據不一致性：緩存層和存儲層的數據存在著一定時間窗口的不一致性，時間窗口跟更新策略有關。
• 代碼維護成本：加入緩存后，需要同時處理緩存層和存儲層的邏輯，增大了開發者維護代碼的成本。
• 運維成本：以Redis Cluster為例，加入后無形中增加了運維成本。

1.3 使用場景

• 開銷大的復雜計算：以MySQL為例子，一些復雜的操作或者計算（例如大量聯表操作、一些分組計算），如果不加緩存，不但無法滿足高并發量，同時也會給MySQL帶來巨大的負擔。
• 加速請求響應：即使查詢單條后端數據足夠快，那么依然可以使用緩存，以Redis為例子，每秒可以完成數萬次讀寫，并且提供的批量操作可以優化整個IO鏈的響應時間

二、緩存更新策略

2.1 內存溢出淘汰策略

思考：在生產環境的 redis 經常會丟掉一些數據，寫進去了，過一會兒可能就沒了。是什么原因？

Redis 緩存通常都是全內存，內存是很寶貴而且是有限的，磁盤是廉價而且是大量的。可能一臺機器就幾十個 G 的內存，但是可以有幾個 T 的硬盤空間。Redis 主要是基于內存來進行高性能、高并發的讀寫操作。那既然內存是有限，比如 redis 就只能用 10G，你要是往里面寫了 20G 的數據，會咋辦？當然會干掉 10G 的數據，然后就保留 10G 的數據了。那干掉哪些數據？保留哪些數據？當然是干掉不常用的數據，保留常用的數據了。數據明明過期了，怎么還占用著內存？這是由 redis 的過期策略來決定。

在Redis中，當所用內存達到maxmemory上限（used_memory>maxmemory）時會觸發相應的溢出控制策略。具體策略受maxmemory-policy參數控制。

Redis支持6種策略：

• noeviction：默認策略，不會刪除任何數據，拒絕所有寫入操作并返回客戶端錯誤信息（error）OOM command not allowed when used memory，此時Redis只響應讀操作
• volatile-lru：根據LRU算法刪除設置了超時屬性（expire）的鍵，直到騰出足夠空間為止。如果沒有可刪除的鍵對象，回退到noeviction策略
• volatile-random：隨機刪除過期鍵，直到騰出足夠空間為止
• allkeys-lru：根據LRU算法刪除鍵，不管數據有沒有設置超時屬性，直到騰出足夠空間為止
• allkeys-random：隨機刪除所有鍵，直到騰出足夠空間為止（不推薦）
• volatile-ttl：根據鍵值對象的ttl（剩余時間(time to live,TTL) ）屬性，刪除最近將要過期數據。如果沒有，回退到noeviction策略

LRU :Least Recently Used ，最近最少使用的，緩存的元素有一個時間戳，當緩存容量滿了，而又需要騰出地方來緩存新的元素的時候，那么現有緩存元素中時間戳離當前時間最遠的元素將被清出緩存。 ? ? ??

內存溢出控制策略可以采用config set maxmemory-policy{policy}動態配置。寫命令導致當內存溢出時會頻繁執行回收內存成本很高，在主從復制架構中，回收內存操作對應的刪除命令會同步到從節點來，來保障主從節點數據一致性，從而導致寫放大的問題。

2.2 過期策略

Redis 服務端采用的 過期策略是 ： 惰性刪除 + 定期刪除

惰性刪除：?

Redis的每個庫都有一個過期字典，過期字典中保存所有key的過期時間。當客戶端讀取一個key時會先到過期字典內查詢key是否已經過期，如果key已經超過，會執行刪除操作并返回空。這種策略是出于節省CPU成本考慮，但是單獨用這種方式存在內存泄露的問題，當過期鍵一直沒有訪問將無法得到及時刪除，從而導致內存不能及時釋放。

定時刪除：

Redis內部維護一個定時任務，默認每秒運行10次過期掃描（通過 redis.conf 中通過 hz 配置 修改運行次數），掃描并不是遍歷過期字典中的所有鍵，而是采用了自適應算法，根據鍵的過期比例、使用快慢兩種速率模式回收鍵：

1.從過期字典中隨機取出 20 個鍵
2.刪除這 20 個鍵中過期的鍵
3.如果過期鍵的比例超過 25% ，重復步驟 1 和 2

為了保證掃描不會出現循環過度，一直在執行定時刪除定時任務無法對外提供服務，導致線程卡死現象，還增加了掃描時間的上限，默認是 25 毫秒（即默認在慢模式下，25毫秒還未執行完，切換為塊模式，模式下超時時間為1毫秒且2秒內只能運行1次，當慢模式執行完畢正常退出，會重新切回快模式）

三、應用方更新

1.應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
2.先刪除緩存，再更新數據庫：這個操作有一個比較大的問題，更新數據的請求在對緩存刪除完之后，又收到一個讀請求，這個時候由于緩存被刪除所以直接會讀庫，讀操作的數據是老的并且會被加載進入緩存當中，后續讀請求全部訪問的老數據。
3.先更新數據庫，再刪除緩存(推薦)為什么不是寫完數據庫后更新緩存？主要是怕兩個并發的寫操作導致臟數據。

四、緩存粒度

1 ?通用性

緩存全部數據比部分數據更加通用，但從實際經驗看，很長時間內應用只需要幾個重要的屬性。

2 占用空間

緩存全部數據要比部分數據占用更多的空間，存在以下問題：

• 全部數據會造成內存的浪費。
• 全部數據可能每次傳輸產生的網絡流量會比較大，耗時相對較大，在極端情況下會阻塞網絡。
• 全部數據的序列化和反序列化的CPU開銷更大。

3 代碼維護

全部數據的優勢更加明顯，而部分數據一旦要加新字段需要修改業務代碼，而且修改后通常還需要刷新緩存數據。