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

一、緩存的收益與成本

1.1 收益

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

1.2 成本

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

1.3 使用場景

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

二、緩存更新策略

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

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

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

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

Redis支持6種策略：

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

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

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

2.2 過期策略

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

惰性刪除： 

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

定時(shí)刪除：

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

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

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

三、應(yīng)用方更新

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

四、緩存粒度

1  通用性

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

2 占用空間

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

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

3 代碼維護(hù)

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

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論