淺談Redis?中的過期刪除策略和內(nèi)存淘汰機(jī)制
前言
Redis 中的 key 設(shè)置一個(gè)過期時(shí)間,在過期時(shí)間到的時(shí)候,Redis 是如何清除這個(gè) key 的呢?
這來分析下 Redis 中的過期刪除策略和內(nèi)存淘汰機(jī)制
Redis 中 key 的過期刪除策略
Redis 中提供了三種過期刪除的策略
1、定時(shí)刪除
在設(shè)置某個(gè) key 的過期時(shí)間同時(shí),我們創(chuàng)建一個(gè)定時(shí)器,讓定時(shí)器在該過期時(shí)間到來時(shí),立即執(zhí)行對(duì)其進(jìn)行刪除的操作。
優(yōu)點(diǎn):
通過使用定時(shí)器,可以保證過期 key 可以被盡快的刪除,并且釋放過期 key 所占用的內(nèi)存
缺點(diǎn):
對(duì) CPU 是不友好的,當(dāng)過期鍵比較多的時(shí)候,刪除過期 key 會(huì)占用相當(dāng)一部分的 CPU 資源,對(duì)服務(wù)器的響應(yīng)時(shí)間和吞吐量造成影響。
2、惰性刪除
惰性刪除,當(dāng)一個(gè)鍵值對(duì)過期的時(shí)候,只有再次用到這個(gè)鍵值對(duì)的時(shí)候才去檢查刪除這個(gè)鍵值對(duì),也就是如果用不著,這個(gè)鍵值對(duì)就會(huì)一直存在。
優(yōu)點(diǎn):
對(duì) CPU 是友好的,只有在取出鍵值對(duì)的時(shí)候才會(huì)進(jìn)行過期檢查,這樣就不會(huì)把 CPU 資源花費(fèi)在其他無關(guān)緊要的鍵值對(duì)的過期刪除上。
缺點(diǎn):
如果一些鍵值對(duì)永遠(yuǎn)不會(huì)被再次用到,那么將不會(huì)被刪除,最終會(huì)造成內(nèi)存泄漏,無用的垃圾數(shù)據(jù)占用了大量的資源,但是服務(wù)器卻不能去刪除。
看下源碼
// https://github.com/redis/redis/blob/6.2/src/db.c#L1541 // 當(dāng)訪問到 key 的時(shí)候,會(huì)調(diào)用這個(gè)函數(shù),因?yàn)橛械?key 雖然已經(jīng)過期了,但是還可能存在于內(nèi)存中 // key 仍然有效,函數(shù)返回值為0,否則,如果 key 過期,函數(shù)返回1。 int expireIfNeeded(redisDb *db, robj *key) { // 沒有過期 if (!keyIsExpired(db,key)) return 0; // 從庫(kù)的過期是主庫(kù)控制的,是不會(huì)進(jìn)行刪除操作的 // 上面已經(jīng)判斷過是否到期了,所以這里的 key 肯定是過期的 key ,不過如果是主節(jié)點(diǎn)創(chuàng)建的 key 從節(jié)點(diǎn)就不刪除,只會(huì)返回已經(jīng)過期了 if (server.masterhost != NULL) return 1; ... /* Delete the key */ // 刪除 key deleteExpiredKeyAndPropagate(db,key); return 1; }
可以看到每次操作對(duì)應(yīng)的 key 是會(huì)檢查 key 是否過期,如果過期則會(huì)刪除對(duì)應(yīng)的 key 。
如果過期鍵是主庫(kù)創(chuàng)建的,那么從庫(kù)進(jìn)行檢查是不會(huì)進(jìn)行刪除操作的,只是會(huì)根據(jù) key 的過期時(shí)間返回過期或者未過期的狀態(tài)。
3、定期刪除
定期刪除是對(duì)上面兩種刪除策略的一種整合和折中
每個(gè)一段時(shí)間就對(duì)一些 key 進(jìn)行采樣檢查,檢查是否過期,如果過期就進(jìn)行刪除
1、采樣一定個(gè)數(shù)的key,采樣的個(gè)數(shù)可以進(jìn)行配置,并將其中過期的 key 全部刪除;
2、如果過期 key 的占比超過可接受的過期 key 的百分比
,則重復(fù)刪除的過程,直到過期key的比例降至可接受的過期 key 的百分比
以下。
優(yōu)點(diǎn):
定期刪除,通過控制定期刪除執(zhí)行的時(shí)長(zhǎng)和頻率,可以減少刪除操作對(duì) CPU 的影響,同時(shí)也能較少因過期鍵帶來的內(nèi)存的浪費(fèi)。
缺點(diǎn):
執(zhí)行的頻率不太好控制
頻率過快對(duì) CPU 不友好,如果過慢了就會(huì)對(duì)內(nèi)存不太友好,過期的鍵值對(duì)不能及時(shí)的被刪除掉
同時(shí)如果一個(gè)鍵值對(duì)過期了,但是沒有被刪除,這時(shí)候業(yè)務(wù)再次獲取到這個(gè)鍵值對(duì),那么就會(huì)獲取到被刪除的數(shù)據(jù)了,這肯定是不合理的。
看下源碼實(shí)現(xiàn)
// https://github.com/redis/redis/blob/6.2/src/server.c#L1853 // 這個(gè)函數(shù)處理我們需要在Redis數(shù)據(jù)庫(kù)中增量執(zhí)行的“后臺(tái)”操作,例如活動(dòng)鍵過期,調(diào)整大小,重哈希。 void databasesCron(void) { // 通過隨機(jī)抽樣來過期 // 這里區(qū)分了主節(jié)點(diǎn)和從節(jié)點(diǎn)的處理 if (server.active_expire_enabled) { if (iAmMaster()) { activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW); } else { expireSlaveKeys(); } } ... } // https://github.com/redis/redis/blob/6.2/src/expire.c#L113 void activeExpireCycle(int type) { // 根據(jù)配置的超時(shí)工作調(diào)整運(yùn)行參數(shù)。默認(rèn)工作量為1,最大可配置工作量為10 unsigned long effort = server.active_expire_effort-1, /* Rescale from 0 to 9. */ // 采樣的 key 的數(shù)量 config_keys_per_loop = ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP + ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP/4*effort, // 占比CPU時(shí)間,默認(rèn)是25%,最大43%,如果是100%,那除了定時(shí)刪除其他的工作都做不了了,所以要做限制 config_cycle_slow_time_perc = ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC + 2*effort, // 可接受的過期 key 的百分比 config_cycle_acceptable_stale = ACTIVE_EXPIRE_CYCLE_ACCEPTABLE_STALE- effort; ... //慢速定期刪除的執(zhí)行時(shí)長(zhǎng) timelimit = config_cycle_slow_time_perc*1000000/server.hz/100; timelimit_exit = 0; ... // 在 key 過期時(shí)積累一些全局統(tǒng)計(jì)信息,以便了解邏輯上已經(jīng)過期但仍存在于數(shù)據(jù)庫(kù)中的 key 的數(shù)量 long total_sampled = 0; long total_expired = 0; for (j = 0; j < dbs_per_call && timelimit_exit == 0; j++) { ... // 如果超過 config_cycle_acceptable_stale 的key過期了,則重復(fù)刪除的過程,直到過期key的比例降至 config_cycle_acceptable_stale 以下。 // 存儲(chǔ)在 config_cycle_acceptable_stale 中的百分比不是固定的,而是取決于Redis配置的“expire efforce” do { /* If there is nothing to expire try next DB ASAP. */ if ((num = dictSize(db->expires)) == 0) { db->avg_ttl = 0; break; } ... // 采樣的 key 的數(shù)量 if (num > config_keys_per_loop) num = config_keys_per_loop; ... while (sampled < num && checked_buckets < max_buckets) { for (int table = 0; table < 2; table++) { ... while(de) { /* Get the next entry now since this entry may get * deleted. */ dictEntry *e = de; de = de->next; ttl = dictGetSignedIntegerVal(e)-now; // 過期檢查,并對(duì)過期鍵進(jìn)行刪除 if (activeExpireCycleTryExpire(db,e,now)) expired++; ... } } db->expires_cursor++; } ... // 判斷過期 key 的占比是否大于 config_cycle_acceptable_stale,如果大于持續(xù)進(jìn)行過期 key 的刪除 } while (sampled == 0 || (expired*100/sampled) > config_cycle_acceptable_stale); } ... } // 檢查刪除由從節(jié)點(diǎn)創(chuàng)建的有過期的時(shí)間的 key void expireSlaveKeys(void) { // 從主庫(kù)同步的 key,過期時(shí)間由主庫(kù)維護(hù),主庫(kù)同步 DEL 操作到從庫(kù)。 // 從庫(kù)如果是 READ-WRITE 模式,就可以繼續(xù)寫入數(shù)據(jù)。從庫(kù)自己寫入的數(shù)據(jù)就需要自己來維護(hù)其過期操作。 if (slaveKeysWithExpire == NULL || dictSize(slaveKeysWithExpire) == 0) return; ... }
惰性刪除過程
1、固定的時(shí)間執(zhí)行一次定期刪除;
2、采樣一定個(gè)數(shù)的key,采樣個(gè)數(shù)可以進(jìn)行配置,并將其中過期的key全部刪除;
3、如果過期 key 的占比超過可接受的過期 key 的百分比
,則重復(fù)刪除的過程,直到過期key的比例降至可接受的過期 key 的百分比
以下;
4、對(duì)于從庫(kù)創(chuàng)建的過期 key 同樣從庫(kù)是不能進(jìn)行刪除的。
Redis 中過期刪除策略
上面討論的三種策略,都有或多或少的問題。Redis 中實(shí)際采用的策略是惰性刪除加定期刪除的組合方式。
組合方式的使用
定期刪除,獲取 CPU 和 內(nèi)存的使用平衡,針對(duì)過期的 KEY 可能得不到及時(shí)的刪除,當(dāng) KEY 被再次獲取的時(shí)候,通過惰性刪除再做一次過期檢查,來避免業(yè)務(wù)獲取到過期內(nèi)容。
從庫(kù)是否會(huì)臟讀主庫(kù)創(chuàng)建的過期鍵
從上面惰性刪除和定期刪除的源碼閱讀中,我們可以發(fā)現(xiàn),從庫(kù)對(duì)于主庫(kù)的過期鍵是不能主動(dòng)進(jìn)行刪除的。如果一個(gè)主庫(kù)創(chuàng)建的過期鍵值對(duì),已經(jīng)過期了,主庫(kù)在進(jìn)行定期刪除的時(shí)候,沒有及時(shí)的刪除掉,這時(shí)候從庫(kù)請(qǐng)求了這個(gè)鍵值對(duì),當(dāng)執(zhí)行惰性刪除的時(shí)候,因?yàn)槭侵鲙?kù)創(chuàng)建的鍵值對(duì),這時(shí)候是不能在從庫(kù)中刪除的,那么是不是就意味著從庫(kù)會(huì)讀取到已經(jīng)過期的數(shù)據(jù)呢?
答案肯定不是的
how-redis-replication-deals-with-expires-on-keys
How Redis replication deals with expires on keys
Redis expires allow keys to have a limited time to live. Such a feature depends on the ability of an instance to count the time, however Redis slaves correctly replicate keys with expires, even when such keys are altered using Lua scripts.
To implement such a feature Redis cannot rely on the ability of the master and slave to have synchronized clocks, since this is a problem that cannot be solved and would result into race conditions and diverging data sets, so Redis uses three main techniques in order to make the replication of expired keys able to work:
1.Slaves don’t expire keys, instead they wait for masters to expire the keys. When a master expires a key (or evict it because of LRU), it synthesizes a DEL command which is transmitted to all the slaves.
2.However because of master-driven expire, sometimes slaves may still have in memory keys that are already logically expired, since the master was not able to provide the DEL command in time. In order to deal with that the slave uses its logical clock in order to report that a key does not exist only for read operations that don’t violate the consistency of the data set (as new commands from the master will arrive). In this way slaves avoid to report logically expired keys are still existing. In practical terms, an HTML fragments cache that uses slaves to scale will avoid returning items that are already older than the desired time to live.
3.During Lua scripts executions no keys expires are performed. As a Lua script runs, conceptually the time in the master is frozen, so that a given key will either exist or not for all the time the script runs. This prevents keys to expire in the middle of a script, and is needed in order to send the same script to the slave in a way that is guaranteed to have the same effects in the data set.
Once a slave is promoted to a master it will start to expire keys independently, and will not require any help from its old master.
上面是官方文檔中針對(duì)這一問題的描述
大概意思就是從節(jié)點(diǎn)不會(huì)主動(dòng)刪除過期鍵,從節(jié)點(diǎn)會(huì)等待主節(jié)點(diǎn)觸發(fā)鍵過期。當(dāng)主節(jié)點(diǎn)觸發(fā)鍵過期時(shí),主節(jié)點(diǎn)會(huì)同步一個(gè)del命令給所有的從節(jié)點(diǎn)。
因?yàn)槭侵鞴?jié)點(diǎn)驅(qū)動(dòng)刪除的,所以從節(jié)點(diǎn)會(huì)獲取到已經(jīng)過期的鍵值對(duì)。從節(jié)點(diǎn)需要根據(jù)自己本地的邏輯時(shí)鐘來判斷減值是否過期,從而實(shí)現(xiàn)數(shù)據(jù)集合的一致性讀操作。
我們知道 Redis 中的過期策略是惰性刪除和定期刪除,所以每個(gè)鍵值的操作,都會(huì)使用惰性刪除來檢查是否過期,然后判斷是否可以進(jìn)行刪除
// https://github.com/redis/redis/blob/6.2/src/db.c#L1541 // 當(dāng)訪問到 key 的時(shí)候,會(huì)調(diào)用這個(gè)函數(shù),因?yàn)橛械?key 雖然已經(jīng)過期了,但是還可能存在于內(nèi)存中 // key 仍然有效,函數(shù)返回值為0,否則,如果 key 過期,函數(shù)返回1。 int expireIfNeeded(redisDb *db, robj *key) { // 檢查 key 是否過期 if (!keyIsExpired(db,key)) return 0; // 從庫(kù)的過期是主庫(kù)控制的,是不會(huì)進(jìn)行刪除操作的 // 上面已經(jīng)判斷過是否到期了,所以這里的 key 肯定設(shè)計(jì)過期的 key ,不過如果是主節(jié)點(diǎn)創(chuàng)建的 key 從節(jié)點(diǎn)就不刪除,只會(huì)返回已經(jīng)過期了 if (server.masterhost != NULL) return 1; ... /* Delete the key */ // 刪除 key deleteExpiredKeyAndPropagate(db,key); return 1; } // https://github.com/redis/redis/blob/6.2/src/db.c#L1485 /* Check if the key is expired. */ int keyIsExpired(redisDb *db, robj *key) { // 過期時(shí)間 mstime_t when = getExpire(db,key); mstime_t now; // 沒有過期 if (when < 0) return 0; /* No expire for this key */ /* Don't expire anything while loading. It will be done later. */ if (server.loading) return 0; // lua 腳本執(zhí)行的過程中不過期 if (server.lua_caller) { now = server.lua_time_snapshot; } // 如果我們正在執(zhí)行一個(gè)命令,我們?nèi)匀幌M褂靡粋€(gè)不會(huì)改變的引用時(shí)間:在這種情況下,我們只使用緩存的時(shí)間,我們?cè)诿看握{(diào)用call()函數(shù)之前更新。 // 這樣我們就避免了RPOPLPUSH之類的命令,這些命令可能會(huì)重新打開相同的鍵多次,如果下次調(diào)用會(huì)看到鍵過期,則會(huì)使已經(jīng)打開的對(duì)象在下次調(diào)用中失效,而第一次調(diào)用沒有。 else if (server.fixed_time_expire > 0) { now = server.mstime; } // 其他情況下,獲取最新的時(shí)間 else { now = mstime(); } // 判斷是否過期了 return now > when; } // 返回指定 key 的過期時(shí)間,如果沒有過期則返回-1 long long getExpire(redisDb *db, robj *key) { dictEntry *de; /* No expire? return ASAP */ if (dictSize(db->expires) == 0 || (de = dictFind(db->expires,key->ptr)) == NULL) return -1; /* The entry was found in the expire dict, this means it should also * be present in the main dict (safety check). */ serverAssertWithInfo(NULL,key,dictFind(db->dict,key->ptr) != NULL); return dictGetSignedIntegerVal(de); }
上面的惰性刪除,對(duì)于主節(jié)點(diǎn)創(chuàng)建的過期 key ,雖然不能進(jìn)行刪除的操作,但是可以進(jìn)行過期時(shí)間的判斷,所以如果主庫(kù)創(chuàng)建的過期鍵,如果主庫(kù)沒有及時(shí)進(jìn)行刪除,這時(shí)候從庫(kù)可以通過惰性刪除來判斷鍵值對(duì)的是否過期,避免讀取到過期的內(nèi)容。
內(nèi)存淘汰機(jī)制
上面我們討論的 Redis 過期策略指的是 Redis 使用那種策略,來刪除已經(jīng)過期的鍵值對(duì)。但是有一些 key以后永遠(yuǎn)用不到了,那么就可能一直不能被刪除掉,還有就是 Redis 中的使用過程中,隨著寫數(shù)據(jù)的增加,Redis 中的內(nèi)存不夠用了,這時(shí)候就需要 Redis 的內(nèi)存淘汰策略了。
Redis 過期策略指的是 Redis 使用那種策略,來刪除已經(jīng)過期的鍵值對(duì);
Redis 內(nèi)存淘汰機(jī)制指的是,當(dāng) Redis 運(yùn)行內(nèi)存已經(jīng)超過 Redis 設(shè)置的最大內(nèi)存之后,將采用什么策略來刪除符合條件的鍵值對(duì),以此來保障 Redis 高效的運(yùn)行。
內(nèi)存淘汰觸發(fā)的最大內(nèi)存
Redis 中的內(nèi)存只有達(dá)到了閥值,才會(huì)觸發(fā)內(nèi)存淘汰算法,這個(gè)閥值就是我們?cè)O(shè)置的最大運(yùn)行內(nèi)存,在配置文件redis.conf
中,通過參數(shù) maxmemory <bytes>
來設(shè)置
查詢最大運(yùn)行內(nèi)存
127.0.0.1:6379> config get maxmemory 1) "maxmemory" 2) "0"
在 64 位操作系統(tǒng)中,當(dāng) maxmemory 為 0 時(shí),表示沒有內(nèi)存大小限制,32位的系統(tǒng)。
有哪些內(nèi)存淘汰策略
當(dāng)現(xiàn)有內(nèi)存大于 maxmemory 時(shí),便會(huì)觸發(fā)redis主動(dòng)淘汰內(nèi)存方式,通過設(shè)置 maxmemory-policy ,有如下幾種淘汰方式:
1、volatile-lru:淘汰所有設(shè)置了過期時(shí)間的鍵值中最久未使用的鍵值;
2、allkeys-lru:淘汰整個(gè)鍵值中最久未使用的鍵值;
3、volatile-random:隨機(jī)淘汰設(shè)置了過期時(shí)間的任意鍵值;
4、allkeys-random:隨機(jī)淘汰任意鍵值;
5、volatile-ttl:優(yōu)先淘汰更早過期的鍵值;
6、noeviction:不淘汰任何數(shù)據(jù),當(dāng)內(nèi)存不足時(shí),新增操作會(huì)報(bào)錯(cuò),Redis 默認(rèn)內(nèi)存淘汰策略;
其中 allkeys-xxx 表示從所有的鍵值中淘汰數(shù)據(jù),而 volatile-xxx 表示從設(shè)置了過期鍵的鍵值中淘汰數(shù)據(jù)。
內(nèi)存淘汰算法
除了隨機(jī)刪除和不刪除之外,主要有兩種淘汰算法:LRU 算法和 LFU 算法。
LRU
LRU 全稱是Least Recently Used
譯為最近最少使用,是一種常用的頁(yè)面置換算法,選擇最近最久未使用的頁(yè)面予以淘汰。
一般 LRU 算法的實(shí)現(xiàn)基于鏈表結(jié)構(gòu),鏈表中的元素按照操作順序從前往后排列,最新操作的鍵會(huì)被移動(dòng)到表頭,當(dāng)需要內(nèi)存淘汰時(shí),只需要?jiǎng)h除鏈表尾部的元素即可。
Redis 使用的是一種近似 LRU 算法,目的是為了更好的節(jié)約內(nèi)存,它的實(shí)現(xiàn)方式是給現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)添加一個(gè)額外的字段,用于記錄此鍵值的最后一次訪問時(shí)間,Redis 內(nèi)存淘汰時(shí),會(huì)使用隨機(jī)采樣的方式來淘汰數(shù)據(jù),它是隨機(jī)取 5 個(gè)值(此值可配置),然后淘汰最久沒有使用的那個(gè)。
這里看下是如何實(shí)現(xiàn)的呢
Redis 在源碼中對(duì)于每個(gè)鍵值對(duì)中的值,會(huì)使用一個(gè) redisObject 結(jié)構(gòu)體來保存指向值的指針,這里先來看下 redisObject 的結(jié)構(gòu)
// https://github.com/redis/redis/blob/6.2/src/server.h#L673 typedef struct redisObject { unsigned type:4; unsigned encoding:4; // 這里保存 // LRU時(shí)間(相對(duì)于全局LRU時(shí)鐘) // LFU數(shù)據(jù) (低 8 bits 作為計(jì)數(shù)器,用 24 bits 中的高 16 bits,記錄訪問的時(shí)間戳) unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or * LFU data (least significant 8 bits frequency * and most significant 16 bits access time). */ int refcount; void *ptr; } robj;
當(dāng)一個(gè)鍵值對(duì)被創(chuàng)建的時(shí)候,就會(huì)記錄下更新的時(shí)間
// https://github.com/redis/redis/blob/6.2/src/object.c#L41 robj *createObject(int type, void *ptr) { robj *o = zmalloc(sizeof(*o)); o->type = type; o->encoding = OBJ_ENCODING_RAW; o->ptr = ptr; o->refcount = 1; // 如果緩存替換策略是LFU,那么將lru變量設(shè)置為L(zhǎng)FU的計(jì)數(shù)值 if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { o->lru = (LFUGetTimeInMinutes()<<8) | LFU_INIT_VAL; } else { // 如果是 lru // 調(diào)用LRU_CLOCK函數(shù)獲取LRU時(shí)鐘值 o->lru = LRU_CLOCK(); } return o; }
同時(shí)一個(gè)鍵值對(duì)被訪問的時(shí)候記錄的時(shí)間也會(huì)被更新,當(dāng)一個(gè)鍵值對(duì)被訪問時(shí),訪問操作最終都會(huì)調(diào)用 lookupKey 函數(shù)。
// https://github.com/redis/redis/blob/6.2/src/db.c#L63 robj *lookupKey(redisDb *db, robj *key, int flags) { dictEntry *de = dictFind(db->dict,key->ptr); if (de) { robj *val = dictGetVal(de); /* Update the access time for the ageing algorithm. * Don't do it if we have a saving child, as this will trigger * a copy on write madness. */ if (!hasActiveChildProcess() && !(flags & LOOKUP_NOTOUCH)){ if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { updateLFU(val); } else { // 使用 LRU 更新 lru 的時(shí)間 val->lru = LRU_CLOCK(); } } return val; } else { return NULL; } }
上面我們分別看了,創(chuàng)建和訪問一個(gè)鍵值對(duì)的代碼,每次操作,redisObject 中記錄的 lru 時(shí)間就會(huì)被同步的更新
Redis 會(huì)判斷當(dāng)前內(nèi)存的使用情況,如果超過了 maxmemory 配置的值,就會(huì)觸發(fā)新的內(nèi)存淘汰了
如果內(nèi)存超過了 maxmemory 的值,這時(shí)候還需要去計(jì)算需要釋放的內(nèi)存量,這個(gè)釋放的內(nèi)存大小等于已使用的內(nèi)存量減去 maxmemory。不過,已使用的內(nèi)存量并不包括用于主從復(fù)制的復(fù)制緩沖區(qū)大小。
// https://github.com/redis/redis/blob/6.2/src/evict.c#L512 int performEvictions(void) { ... while (mem_freed < (long long)mem_tofree) { int j, k, i; static unsigned int next_db = 0; sds bestkey = NULL; int bestdbid; redisDb *db; dict *dict; dictEntry *de; if (server.maxmemory_policy & (MAXMEMORY_FLAG_LRU|MAXMEMORY_FLAG_LFU) || server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL) { struct evictionPoolEntry *pool = EvictionPoolLRU; while(bestkey == NULL) { unsigned long total_keys = 0, keys; /* We don't want to make local-db choices when expiring keys, * so to start populate the eviction pool sampling keys from * every DB. */ // 根據(jù)淘汰策略,決定使用全局哈希表還是設(shè)置了過期時(shí)間的key的哈希表 for (i = 0; i < server.dbnum; i++) { db = server.db+i; dict = (server.maxmemory_policy & MAXMEMORY_FLAG_ALLKEYS) ? db->dict : db->expires; if ((keys = dictSize(dict)) != 0) { // 將選擇的哈希表dict傳入evictionPoolPopulate函數(shù),同時(shí)將全局哈希表也傳給evictionPoolPopulate函數(shù) evictionPoolPopulate(i, dict, db->dict, pool); total_keys += keys; } } ... } } ... } // 用來填充evictionPool // 按升序插入鍵,所以空閑時(shí)間小的鍵在左邊,空閑時(shí)間高的鍵在右邊。 // https://github.com/redis/redis/blob/6.2/src/evict.c#L145 void evictionPoolPopulate(int dbid, dict *sampledict, dict *keydict, struct evictionPoolEntry *pool) { int j, k, count; dictEntry *samples[server.maxmemory_samples]; count = dictGetSomeKeys(sampledict,samples,server.maxmemory_samples); for (j = 0; j < count; j++) { ... // 將元素插入池中。 首先,找到第一個(gè)空閑時(shí)間小于我們空閑時(shí)間的空桶或第一個(gè)填充的桶。 k = 0; while (k < EVPOOL_SIZE && pool[k].key && pool[k].idle < idle) k++; if (k == 0 && pool[EVPOOL_SIZE-1].key != NULL) { /* Can't insert if the element is < the worst element we have * and there are no empty buckets. */ continue; } else if (k < EVPOOL_SIZE && pool[k].key == NULL) { /* Inserting into empty position. No setup needed before insert. */ } else { /* Inserting in the middle. Now k points to the first element * greater than the element to insert. */ if (pool[EVPOOL_SIZE-1].key == NULL) { /* Free space on the right? Insert at k shifting * all the elements from k to end to the right. */ /* Save SDS before overwriting. */ sds cached = pool[EVPOOL_SIZE-1].cached; memmove(pool+k+1,pool+k, sizeof(pool[0])*(EVPOOL_SIZE-k-1)); pool[k].cached = cached; } else { /* No free space on right? Insert at k-1 */ k--; /* Shift all elements on the left of k (included) to the * left, so we discard the element with smaller idle time. */ sds cached = pool[0].cached; /* Save SDS before overwriting. */ if (pool[0].key != pool[0].cached) sdsfree(pool[0].key); memmove(pool,pool+1,sizeof(pool[0])*k); pool[k].cached = cached; } } ... } }
處理淘汰的數(shù)據(jù),Redis 中提供了一個(gè)數(shù)組 EvictionPoolLRU,用來保存待淘汰的候選鍵值對(duì)。這個(gè)數(shù)組的元素類型是 evictionPoolEntry 結(jié)構(gòu)體,該結(jié)構(gòu)體保存了待淘汰鍵值對(duì)的空閑時(shí)間 idle、對(duì)應(yīng)的 key 等信息。
可以看到上面的上面會(huì)選取一定的過期鍵,然后插入到 EvictionPoolLRU 中
dictGetSomeKeys 函數(shù)采樣的 key 的數(shù)量,是由 redis.conf 中的配置項(xiàng) maxmemory-samples 決定的,該配置項(xiàng)的默認(rèn)值是 5
// https://github.com/redis/redis/blob/6.2/src/evict.c#L55 struct evictionPoolEntry { // 待淘汰的鍵值對(duì)的空閑時(shí)間 unsigned long long idle; /* Object idle time (inverse frequency for LFU) */ // 待淘汰的鍵值對(duì)的key sds key; /* Key name. */ // 緩存的SDS對(duì)象 sds cached; /* Cached SDS object for key name. */ // 待淘汰鍵值對(duì)的key所在的數(shù)據(jù)庫(kù)ID int dbid; /* Key DB number. */ }; static struct evictionPoolEntry *EvictionPoolLRU;
然后通過 evictionPoolPopulate 函數(shù),進(jìn)行采樣,然后將采樣數(shù)據(jù)寫入到 EvictionPoolLRU 中,插入到 EvictionPoolLRU 中的數(shù)據(jù)是按照空閑時(shí)間從小到大進(jìn)行排好序的
freeMemoryIfNeeded 函數(shù)會(huì)遍歷一次 EvictionPoolLRU 數(shù)組,從數(shù)組的最后一個(gè) key 開始選擇,如果選到的 key 不是空值,那么就把它作為最終淘汰的 key。
// https://github.com/redis/redis/blob/6.2/src/evict.c#L512 int performEvictions(void) { if (!isSafeToPerformEvictions()) return EVICT_OK; int keys_freed = 0; size_t mem_reported, mem_tofree; long long mem_freed; /* May be negative */ mstime_t latency, eviction_latency; long long delta; int slaves = listLength(server.slaves); int result = EVICT_FAIL; if (getMaxmemoryState(&mem_reported,NULL,&mem_tofree,NULL) == C_OK) return EVICT_OK; ... while (mem_freed < (long long)mem_tofree) { if (server.maxmemory_policy & (MAXMEMORY_FLAG_LRU|MAXMEMORY_FLAG_LFU) || server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL) { struct evictionPoolEntry *pool = EvictionPoolLRU; while(bestkey == NULL) { unsigned long total_keys = 0, keys; ... /* Go backward from best to worst element to evict. */ // 從數(shù)組最后一個(gè)key開始查找 for (k = EVPOOL_SIZE-1; k >= 0; k--) { // 當(dāng)前key為空值,則查找下一個(gè)key if (pool[k].key == NULL) continue; bestdbid = pool[k].dbid; // 從全局哈希表或是expire哈希表中,獲取當(dāng)前key對(duì)應(yīng)的鍵值對(duì); if (server.maxmemory_policy & MAXMEMORY_FLAG_ALLKEYS) { de = dictFind(server.db[pool[k].dbid].dict, pool[k].key); } else { de = dictFind(server.db[pool[k].dbid].expires, pool[k].key); } /* Remove the entry from the pool. */ // 將當(dāng)前key從EvictionPoolLRU數(shù)組刪除 if (pool[k].key != pool[k].cached) sdsfree(pool[k].key); pool[k].key = NULL; pool[k].idle = 0; /* If the key exists, is our pick. Otherwise it is * a ghost and we need to try the next element. */ // 如果當(dāng)前key對(duì)應(yīng)的鍵值對(duì)不為空,選擇當(dāng)前key為被淘汰的key if (de) { bestkey = dictGetKey(de); break; } else { /* Ghost... Iterate again. */ } } } } ... /* Finally remove the selected key. */ if (bestkey) { db = server.db+bestdbid; robj *keyobj = createStringObject(bestkey,sdslen(bestkey)); propagateExpire(db,keyobj,server.lazyfree_lazy_eviction); delta = (long long) zmalloc_used_memory(); latencyStartMonitor(eviction_latency); // 惰性刪除 if (server.lazyfree_lazy_eviction) dbAsyncDelete(db,keyobj); else // 同步刪除 dbSyncDelete(db,keyobj); ... } } ... }
每次選中一部分過期的鍵值對(duì),每次淘汰最久沒有使用的那個(gè),如果釋放的內(nèi)存空間還不夠,就會(huì)重復(fù)的進(jìn)行采樣,刪除的過程。
LFU
除了 LRU 算法,Redis 在 4.0 版本引入了 LFU 算法,就是最不頻繁使用(Least Frequently Used,LFU)
算法。
LRU 算法:淘汰最近最少使用的數(shù)據(jù),它是根據(jù)時(shí)間維度來選擇將要淘汰的元素,即刪除掉最長(zhǎng)時(shí)間沒被訪問的元素。
LFU 算法:淘汰最不頻繁訪問的數(shù)據(jù),它是根據(jù)頻率維度來選擇將要淘汰的元素,即刪除訪問頻率最低的元素。如果兩個(gè)元素的訪問頻率相同,則淘汰最久沒被訪問的元素。
LFU 的基本原理
LFU(Least Frequently Used)算法,即最少訪問算法,根據(jù)訪問緩存的歷史頻率來淘汰數(shù)據(jù),核心思想是“如果數(shù)據(jù)在過去一段時(shí)間被訪問的次數(shù)很少,那么將來被訪問的概率也會(huì)很低”。
它是根據(jù)頻率維度來選擇將要淘汰的元素,即刪除訪問頻率最低的元素。如果兩個(gè)元素的訪問頻率相同,則淘汰最久沒被訪問的元素。也就是說 LFU 淘汰的時(shí)候會(huì)選擇兩個(gè)維度,先比較頻率,選擇訪問頻率最小的元素;如果頻率相同,則按時(shí)間維度淘汰掉最久遠(yuǎn)的那個(gè)元素。
LUF 的實(shí)現(xiàn)可參見LFU實(shí)現(xiàn)詳解
這看下 Redis 中對(duì) LFU 算法的實(shí)現(xiàn)
1、鍵值對(duì)的訪問頻率記錄和更新
上面分析 LRU 的時(shí)候,聊到了 redisObject,Redis 在源碼中對(duì)于每個(gè)鍵值對(duì)中的值,會(huì)使用一個(gè) redisObject 結(jié)構(gòu)體來保存指向值的指針。里面 lru:LRU_BITS
字段記錄了 LRU 算法和 LFU 算法需要的時(shí)間和計(jì)數(shù)器。
// https://github.com/redis/redis/blob/6.2/src/server.h#L673 typedef struct redisObject { unsigned type:4; unsigned encoding:4; // 這里保存 // LRU時(shí)間(相對(duì)于全局LRU時(shí)鐘) // LFU數(shù)據(jù) (低 8 bits 作為計(jì)數(shù)器,用 24 bits 中的高 16 bits,記錄訪問的時(shí)間戳) unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or * LFU data (least significant 8 bits frequency * and most significant 16 bits access time). */ int refcount; void *ptr; } robj;
當(dāng)一個(gè)鍵值對(duì)被創(chuàng)建的時(shí)候,如果使用 LFU 算法,就會(huì)更新 lru 字段記錄的鍵值對(duì)的訪問時(shí)間戳和訪問次數(shù)。
// https://github.com/redis/redis/blob/6.2/src/object.c#L41 robj *createObject(int type, void *ptr) { robj *o = zmalloc(sizeof(*o)); o->type = type; o->encoding = OBJ_ENCODING_RAW; o->ptr = ptr; o->refcount = 1; // 如果緩存替換策略是LFU,lru變量包括以分鐘為精度的UNIX時(shí)間戳和訪問次數(shù)5 if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { o->lru = (LFUGetTimeInMinutes()<<8) | LFU_INIT_VAL; } else { // 如果是 lru // 調(diào)用LRU_CLOCK函數(shù)獲取LRU時(shí)鐘值 o->lru = LRU_CLOCK(); } return o; }
當(dāng)一個(gè)鍵值對(duì)被訪問時(shí),Redis 會(huì)調(diào)用 lookupKey 函數(shù)進(jìn)行查找。當(dāng) maxmemory-policy
設(shè)置使用 LFU 算法時(shí),lookupKey 函數(shù)會(huì)調(diào)用 updateLFU 函數(shù)來更新鍵值對(duì)的訪問頻率,也就是 lru 變量值,如下所示:
// https://github.com/redis/redis/blob/6.2/src/db.c#L63 robj *lookupKey(redisDb *db, robj *key, int flags) { dictEntry *de = dictFind(db->dict,key->ptr); if (de) { robj *val = dictGetVal(de); // 使用LFU算法時(shí),調(diào)用updateLFU函數(shù)更新訪問頻率 if (!hasActiveChildProcess() && !(flags & LOOKUP_NOTOUCH)){ if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { updateLFU(val); } else { // 使用 LRU 更新 lru 的時(shí)間 val->lru = LRU_CLOCK(); } } return val; } else { return NULL; } } // https://github.com/redis/redis/blob/6.2/src/db.c#L54 /* 訪問對(duì)象時(shí)更新 LFU。 * 首先,如果達(dá)到遞減時(shí)間,則遞減計(jì)數(shù)器。 * 然后對(duì)計(jì)數(shù)器進(jìn)行對(duì)數(shù)遞增,并更新訪問時(shí)間。 */ void updateLFU(robj *val) { unsigned long counter = LFUDecrAndReturn(val); counter = LFULogIncr(counter); val->lru = (LFUGetTimeInMinutes()<<8) | counter; } // https://github.com/redis/redis/blob/6.2/src/evict.c#L318 unsigned long LFUDecrAndReturn(robj *o) { // 獲取當(dāng)前鍵值對(duì)的上一次訪問時(shí)間 unsigned long ldt = o->lru >> 8; // 獲取當(dāng)前的訪問次數(shù) unsigned long counter = o->lru & 255; unsigned long num_periods = server.lfu_decay_time ? LFUTimeElapsed(ldt) / server.lfu_decay_time : 0; if (num_periods) // 如果衰減大小小于當(dāng)前訪問次數(shù),那么,衰減后的訪問次數(shù)是當(dāng)前訪問次數(shù)減去衰減大??;否則,衰減后的訪問次數(shù)等于0 counter = (num_periods > counter) ? 0 : counter - num_periods; // 如果衰減大小為0,則返回原來的訪問次數(shù) return counter; }
上面的代碼可以看到,當(dāng)訪問一個(gè)鍵值對(duì)的時(shí)候,首先進(jìn)行了訪問次數(shù)的衰減?
LFU 算法是根據(jù)訪問頻率來淘汰數(shù)據(jù)的,而不只是訪問次數(shù)。如果訪問間隔時(shí)間越長(zhǎng),那么訪問頻率就越低。
因?yàn)?Redis 是使用 lru 變量中的訪問次數(shù)來表示訪問頻率,所以在每次更新鍵值對(duì)的訪問頻率時(shí),就會(huì)通過 LFUDecrAndReturn 函數(shù)對(duì)訪問次數(shù)進(jìn)行衰減。
LFUDecrAndReturn 函數(shù)會(huì)調(diào)用 LFUTimeElapsed 函數(shù)(在 evict.c 文件中),計(jì)算距離鍵值對(duì)的上一次訪問已經(jīng)過去的時(shí)長(zhǎng)。這個(gè)時(shí)長(zhǎng)也是以 1 分鐘為精度來計(jì)算的。有了距離上次訪問的時(shí)長(zhǎng)后,LFUDecrAndReturn 函數(shù)會(huì)把這個(gè)時(shí)長(zhǎng)除以 lfu_decay_time 的值,并把結(jié)果作為訪問次數(shù)的衰減大小。
lfu_decay_time 變量值,是由 redis.conf 文件中的配置項(xiàng) lfu-decay-time 來決定的。Redis 在初始化時(shí),會(huì)通過 initServerConfig 函數(shù)來設(shè)置 lfu_decay_time 變量的值,默認(rèn)值為 1。所以,在默認(rèn)情況下,訪問次數(shù)的衰減大小就是等于上一次訪問距離當(dāng)前的分鐘數(shù)。
衰減之后,再來看下如何進(jìn)行訪問次數(shù)的更新
// https://github.com/redis/redis/blob/6.2/src/evict.c#L298 uint8_t LFULogIncr(uint8_t counter) { // 等于255,不在進(jìn)行次數(shù)的更新 if (counter == 255) return 255; // 計(jì)算一個(gè)隨機(jī)數(shù) double r = (double)rand()/RAND_MAX; // 計(jì)算當(dāng)前訪問次數(shù)和初始值的差值 double baseval = counter - LFU_INIT_VAL; if (baseval < 0) baseval = 0; // 根據(jù)baseval和lfu_log_factor計(jì)算閾值p double p = 1.0/(baseval*server.lfu_log_factor+1); // 概率值小于閥值 if (r < p) counter++; return counter; }
如果當(dāng)前訪問次數(shù)小于255的時(shí)候,每次 LFULogIncr 函數(shù)會(huì)計(jì)算一個(gè)閾值 p,以及一個(gè)取值為 0 到 1 之間的隨機(jī)概率值 r。如果概率 r 小于閾值 p,那么 LFULogIncr 函數(shù)才會(huì)將訪問次數(shù)加 1。否則的話,LFULogIncr 函數(shù)會(huì)返回當(dāng)前的訪問次數(shù),不做更新。
這樣按照一定的概率增加訪問頻率,避免了訪問次數(shù)過大,8 bits 計(jì)數(shù)器對(duì)訪問次數(shù)的影響。
2、使用 LFU 算法淘汰數(shù)據(jù)
LFU 處理數(shù)據(jù)淘汰和 LRU 方式差不多,這里回顧下 LRU 處理數(shù)據(jù)淘汰的過程
1、調(diào)用 getMaxmemoryState 函數(shù)計(jì)算待釋放的內(nèi)存空間;
2、調(diào)用 evictionPoolPopulate 函數(shù)隨機(jī)采樣鍵值對(duì),并插入到待淘汰集合 EvictionPoolLRU 中;
3、遍歷待淘汰集合 EvictionPoolLRU,選擇實(shí)際被淘汰數(shù)據(jù),并刪除。
不同的是,LFU 算法在淘汰數(shù)據(jù)時(shí),在第二步的 evictionPoolPopulate 函數(shù)中,使用了不同的方法來計(jì)算每個(gè)待淘汰鍵值對(duì)的空閑時(shí)間。
LRU 中 idle 記錄的是它距離上次訪問的空閑時(shí)間。
LFU 中 idle 記錄的是用 255 減去鍵值對(duì)的訪問次數(shù)。也就是鍵值對(duì)訪問次數(shù)越大,它的 idle 值就越小,反之 idle 值越大。
if (server.maxmemory_policy & MAXMEMORY_FLAG_LRU) { idle = estimateObjectIdleTime(o); } else if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) { idle = 255-LFUDecrAndReturn(o); }
freeMemoryIfNeeded 函數(shù)按照 idle 值從大到小,遍歷 EvictionPoolLRU 數(shù)組,選擇實(shí)際被淘汰的鍵值對(duì)時(shí),它就能選出訪問次數(shù)小的鍵值對(duì)了,也就是把訪問頻率低的鍵值對(duì)淘汰出去。
具體的源碼上面 LRU 已經(jīng)展示了,這里不在啰嗦了。
為什么數(shù)據(jù)刪除后內(nèi)存占用還是很高
Redis 中的內(nèi)存可能會(huì)遇到這樣一種情況,雖然進(jìn)行了數(shù)據(jù)的刪除,據(jù)量已經(jīng)不大了,但是使用 top 命令,發(fā)現(xiàn) Redis 還是會(huì)占用大量的內(nèi)存
因?yàn)?,?dāng)數(shù)據(jù)刪除后,Redis 釋放的內(nèi)存空間會(huì)由內(nèi)存分配器管理,并不會(huì)立即返回給操作系統(tǒng)。所以,操作系統(tǒng)仍然會(huì)記錄著給 Redis 分配了大量?jī)?nèi)存。
但是這些內(nèi)存可能是不連續(xù)的,對(duì)于不連續(xù)的小內(nèi)存塊,雖然是空閑內(nèi)存,但是 Redis 缺不能拿來用,會(huì)造成資源的浪費(fèi)。
為什么會(huì)產(chǎn)生內(nèi)存碎片呢?
內(nèi)存碎片如何產(chǎn)生
1、內(nèi)存分配器的分配策略
內(nèi)存分配器對(duì)于內(nèi)存的分配,一般是按固定大小來分配內(nèi)存,而不是完全按照應(yīng)用程序申請(qǐng)的內(nèi)存空間大小給程序分配。
Redis 可以使用 libc、jemalloc、tcmalloc
多種內(nèi)存分配器來分配內(nèi)存,默認(rèn)使用 jemalloc。
jemalloc 的分配策略之一,是按照一系列固定的大小劃分內(nèi)存空間,例如8字節(jié)、16字節(jié)、32字節(jié)、48字節(jié),…, 2KB、4KB、8KB等。當(dāng)程序申請(qǐng)的內(nèi)存最接近某個(gè)固定值時(shí),jemalloc會(huì)給它分配相應(yīng)大小的空間。
這樣的分配方式本身是為了減少分配次數(shù)。例如,Redis申請(qǐng)一個(gè)20字節(jié)的空間保存數(shù)據(jù),jemalloc 就會(huì)分配 32 字節(jié),此時(shí),如果應(yīng)用還要寫入 10 字節(jié)的數(shù)據(jù),Redis 就不用再向操作系統(tǒng)申請(qǐng)空間了,因?yàn)閯偛欧峙涞?2字節(jié)已經(jīng)夠用了,這就避免了一次分配操作。
減少了內(nèi)存分配的次數(shù),缺點(diǎn)就是增加了產(chǎn)生內(nèi)存碎片的可能。
2、鍵值對(duì)的刪除更改操作
Redis 中鍵值對(duì)會(huì)被修改和刪除,這會(huì)導(dǎo)致空間的擴(kuò)容和釋放,一方面,如果修改后的鍵值對(duì)變大或變小了,就需要占用額外的空間或者釋放不用的空間。另一方面,刪除的鍵值對(duì)就不再需要內(nèi)存空間了,此時(shí),就會(huì)把空間釋放出來,形成空閑空間。
Redis中的值刪除的時(shí)候,并沒有把內(nèi)存直接釋放,交還給操作系統(tǒng),而是交給了Redis內(nèi)部有內(nèi)存管理器。
Redis 中申請(qǐng)內(nèi)存的時(shí)候,也是先看自己的內(nèi)存管理器中是否有足夠的內(nèi)存可用。Redis的這種機(jī)制,提高了內(nèi)存的使用率,但是會(huì)使 Redis 中有部分自己沒在用,卻不釋放的內(nèi)存,導(dǎo)致了內(nèi)存碎片的發(fā)生。
碎片率的意義
mem_fragmentation_ratio
的不同值,說明不同的情況。
大于1:說明內(nèi)存有碎片,一般在1到1.5之間是正常的;
大于1.5:說明內(nèi)存碎片率比較大,需要考慮是否要進(jìn)行內(nèi)存碎片清理,要引起重視;
小于1:說明已經(jīng)開始使用交換內(nèi)存,也就是使用硬盤了,正常的內(nèi)存不夠用了,需要考慮是否要進(jìn)行內(nèi)存的擴(kuò)容。
可以使用 INFO memory 命令查看內(nèi)存碎片率
127.0.0.1:6379> INFO memory # Memory used_memory:865672 used_memory_human:845.38K used_memory_rss:8085504 used_memory_rss_human:7.71M used_memory_peak:865672 used_memory_peak_human:845.38K used_memory_peak_perc:100.01% used_memory_overhead:819226 used_memory_startup:802056 used_memory_dataset:46446 used_memory_dataset_perc:73.01% allocator_allocated:995552 allocator_active:1282048 allocator_resident:3690496 total_system_memory:1929736192 total_system_memory_human:1.80G used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction allocator_frag_ratio:1.29 allocator_frag_bytes:286496 allocator_rss_ratio:2.88 allocator_rss_bytes:2408448 rss_overhead_ratio:2.19 rss_overhead_bytes:4395008 mem_fragmentation_ratio:9.80 mem_fragmentation_bytes:7260856 mem_not_counted_for_evict:0 mem_replication_backlog:0 mem_clients_slaves:0 mem_clients_normal:16986 mem_aof_buffer:0 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0
mem_fragmentation_ratio 表示的就是內(nèi)存碎片率
mem_fragmentation_ratio = used_memory_rss/ used_memory
used_memory_rss 是操作系統(tǒng)實(shí)際分配給 Redis 的物理內(nèi)存空間,里面就包含了碎片;而 used_memory 是 Redis 為了保存數(shù)據(jù)實(shí)際申請(qǐng)使用的空間。
如何清理內(nèi)存碎片
Redis服務(wù)器重啟后,Redis會(huì)將沒用的內(nèi)存歸還給操作系統(tǒng),碎片率會(huì)降下來;
4.0 版本的 Redis 引入了自動(dòng)內(nèi)存碎片清理的功能。
自動(dòng)碎片清理,只要設(shè)置了如下的配置,內(nèi)存就會(huì)自動(dòng)清理了。
config set activedefrag yes
不過對(duì)于具體什么時(shí)候開始,受下面兩個(gè)參數(shù)的控制,只要一個(gè)不滿足就停止自動(dòng)清理
active-defrag-ignore-bytes 100mb:表示內(nèi)存碎片的字節(jié)數(shù)達(dá)到100MB時(shí),開始清理;
active-defrag-threshold-lower 10:表示內(nèi)存碎片空間占操作系統(tǒng)分配給Redis的總空間比例達(dá)到10%時(shí),開始清理。
為了保證清理過程中對(duì) CPU 的影響,還設(shè)置了兩個(gè)參數(shù),分別用于控制清理操作占用的CPU時(shí)間比例的上、下限,既保證清理工作能正常進(jìn)行,又避免了降低Redis性能。
active-defrag-cycle-min 25: 表示自動(dòng)清理過程所用CPU時(shí)間的比例不低于25%,保證清理能正常開展;
active-defrag-cycle-max 75:表示自動(dòng)清理過程所用CPU時(shí)間的比例不高于75%,一旦超過,就停止清理,從而避免在清理時(shí),大量的內(nèi)存拷貝阻塞Redis,導(dǎo)致響應(yīng)延遲升高。 、
如果你對(duì)自動(dòng)清理的效果不滿意,可以使用如下命令,直接試下手動(dòng)碎片清理:
memory purge
總結(jié)
1、Redis 中實(shí)際采用的策略是惰性刪除加定期刪除的組合方式;
2、組合的刪除策略,其中定期刪除,獲取 CPU 和 內(nèi)存的使用平衡,針對(duì)過期的 KEY 可能得不到及時(shí)的刪除,當(dāng) KEY 被再次獲取的時(shí)候,通過惰性刪除再做一次過期檢查,來避免業(yè)務(wù)獲取到過期內(nèi)容;
3、刪除的時(shí)候,如果主庫(kù)創(chuàng)建的過期鍵,并且過期了沒有被刪除,這時(shí)候從庫(kù)是會(huì)讀取到內(nèi)容,并且是不能進(jìn)行刪除操作,只能由主庫(kù)操作刪除,不過從庫(kù)會(huì)根據(jù)自己的邏輯時(shí)間判斷這個(gè)過期鍵是否過期,從而避免讀取到過期的數(shù)據(jù);
4、當(dāng) Redis 運(yùn)行內(nèi)存已經(jīng)超過 Redis 設(shè)置的最大內(nèi)存之后,這時(shí)候就會(huì)觸發(fā)內(nèi)存淘汰機(jī)制來清理內(nèi)存,保證 Redis 的正常運(yùn)行;
5、內(nèi)存淘汰機(jī)制一共 6 種淘汰方式;
6、內(nèi)存淘汰機(jī)制里面用到了 LRU 和 LFU;
7、具體的淘汰過程;
1、調(diào)用 getMaxmemoryState 函數(shù)計(jì)算待釋放的內(nèi)存空間;
2、調(diào)用 evictionPoolPopulate 函數(shù)隨機(jī)采樣鍵值對(duì),并插入到待淘汰集合 EvictionPoolLRU 中;
3、遍歷待淘汰集合 EvictionPoolLRU,選擇實(shí)際被淘汰數(shù)據(jù),并刪除。
LRU 和 LFU 不同的是,在第二步的 evictionPoolPopulate 函數(shù)中,使用了不同的方法來計(jì)算每個(gè)待淘汰鍵值對(duì)的空閑時(shí)間。
LRU 中 idle 記錄的是它距離上次訪問的空閑時(shí)間。
LFU 中 idle 記錄的是用 255 減去鍵值對(duì)的訪問次數(shù)。也就是鍵值對(duì)訪問次數(shù)越大,它的 idle 值就越小,反之 idle 值越大。
8、刪除鍵值對(duì)之后, Redis 中的內(nèi)存占用也可能很高,Redis中的值刪除的時(shí)候,并沒有把內(nèi)存直接釋放,交還給操作系統(tǒng),而是交給了Redis內(nèi)部有內(nèi)存管理器。這樣就意味著有內(nèi)存碎片的產(chǎn)生,我們需要注意去清理。
參考
【Redis核心技術(shù)與實(shí)戰(zhàn)】https://time.geekbang.org/column/intro/100056701
【Redis設(shè)計(jì)與實(shí)現(xiàn)】https://book.douban.com/subject/25900156/
【Redis 源碼剖析與實(shí)戰(zhàn)】https://time.geekbang.org/column/intro/100084301
【Redis中過期鍵的刪除】https://boilingfrog.github.io/2022/04/02/Redis中過期鍵的刪除/
【Redis學(xué)習(xí)筆記】https://github.com/boilingfrog/Go-POINT/tree/master/redis
到此這篇關(guān)于淺談Redis 中的過期刪除策略和內(nèi)存淘汰機(jī)制的文章就介紹到這了,更多相關(guān)Redis 過期刪除和內(nèi)存淘汰內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
高效異步redis客戶端aredis優(yōu)劣勢(shì)原理解析
這篇文章主要介紹了高效異步redis客戶端aredis優(yōu)劣勢(shì)原理解析,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-09-09一起raid數(shù)據(jù)恢復(fù)及回遷成功的案例
這篇文章主要介紹了一起raid數(shù)據(jù)恢復(fù)及回遷成功的案例,需要的朋友可以參考下2017-04-04Redis之SDS數(shù)據(jù)結(jié)構(gòu)的使用
本文主要介紹了Redis之SDS數(shù)據(jù)結(jié)構(gòu)的使用,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-08-08Redis fork進(jìn)程分配不到內(nèi)存解決方案
這篇文章主要介紹了Redis fork進(jìn)程分配不到內(nèi)存解決方案,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-11-11