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

一、緩存的收益與成本

1.1 收益

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

1.2 成本

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

1.3 使用場景

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

二、緩存更新策略

2.1 內(nèi)存溢出淘汰策略

思考：在生產(chǎn)環(huán)境的 redis 經(jīng)常會丟掉一些數(shù)據(jù)，寫進去了，過一會兒可能就沒了。是什么原因？

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

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

Redis支持6種策略：

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

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

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

2.2 過期策略

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

惰性刪除：?

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

定時刪除：

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

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

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

三、應用方更新

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

四、緩存粒度

1 ?通用性

緩存全部數(shù)據(jù)比部分數(shù)據(jù)更加通用，但從實際經(jīng)驗看，很長時間內(nèi)應用只需要幾個重要的屬性。

2 占用空間

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

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

3 代碼維護

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