Redis中過(guò)期鍵怎么刪除

這篇“Redis中過(guò)期鍵怎么刪除”文章的知識(shí)點(diǎn)大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來(lái)看看這篇“Redis中過(guò)期鍵怎么刪除”文章吧。

前言

Redis 中的 key 設(shè)置一個(gè)過(guò)期時(shí)間，在過(guò)期時(shí)間到的時(shí)候，Redis 是如何清除這個(gè) key 的呢？

這來(lái)分析下 Redis 中的過(guò)期刪除策略和內(nèi)存淘汰機(jī)制

Redis 中 key 的過(guò)期刪除策略

Redis 中提供了三種過(guò)期刪除的策略

1、定時(shí)刪除

在設(shè)置某個(gè) key 的過(guò)期時(shí)間同時(shí)，我們創(chuàng)建一個(gè)定時(shí)器，讓定時(shí)器在該過(guò)期時(shí)間到來(lái)時(shí)，立即執(zhí)行對(duì)其進(jìn)行刪除的操作。

優(yōu)點(diǎn)：

通過(guò)使用定時(shí)器，可以保證過(guò)期 key 可以被盡快的刪除，并且釋放過(guò)期 key 所占用的內(nèi)存

缺點(diǎn)：

對(duì) CPU 是不友好的，當(dāng)過(guò)期鍵比較多的時(shí)候，刪除過(guò)期 key 會(huì)占用相當(dāng)一部分的 CPU 資源，對(duì)服務(wù)器的響應(yīng)時(shí)間和吞吐量造成影響。

2、惰性刪除

惰性刪除，當(dāng)一個(gè)鍵值對(duì)過(guò)期的時(shí)候，只有再次用到這個(gè)鍵值對(duì)的時(shí)候才去檢查刪除這個(gè)鍵值對(duì)，也就是如果用不著，這個(gè)鍵值對(duì)就會(huì)一直存在。

優(yōu)點(diǎn)：

對(duì) CPU 是友好的，只有在取出鍵值對(duì)的時(shí)候才會(huì)進(jìn)行過(guò)期檢查，這樣就不會(huì)把 CPU 資源花費(fèi)在其他無(wú)關(guān)緊要的鍵值對(duì)的過(guò)期刪除上。

缺點(diǎn)：

如果一些鍵值對(duì)永遠(yuǎn)不會(huì)被再次用到，那么將不會(huì)被刪除，最終會(huì)造成內(nèi)存泄漏，無(wú)用的垃圾數(shù)據(jù)占用了大量的資源，但是服務(wù)器卻不能去刪除。

看下源碼

// https://github.com/redis/redis/blob/6.2/src/db.c#L1541
// 當(dāng)訪問(wèn)到 key 的時(shí)候，會(huì)調(diào)用這個(gè)函數(shù)，因?yàn)橛械?nbsp;key 雖然已經(jīng)過(guò)期了，但是還可能存在于內(nèi)存中

// key 仍然有效，函數(shù)返回值為0，否則，如果 key 過(guò)期，函數(shù)返回1。
int expireIfNeeded(redisDb *db, robj *key) {
    // 沒(méi)有過(guò)期
    if (!keyIsExpired(db,key)) return 0;

    // 從庫(kù)的過(guò)期是主庫(kù)控制的，是不會(huì)進(jìn)行刪除操作的
    // 上面已經(jīng)判斷過(guò)是否到期了，所以這里的 key 肯定是過(guò)期的 key ,不過(guò)如果是主節(jié)點(diǎn)創(chuàng)建的 key 從節(jié)點(diǎn)就不刪除，只會(huì)返回已經(jīng)過(guò)期了
    if (server.masterhost != NULL) return 1;
    ...
    /* Delete the key */
    // 刪除 key 
    deleteExpiredKeyAndPropagate(db,key);
    return 1;
}

可以看到每次操作對(duì)應(yīng)的 key 是會(huì)檢查 key 是否過(guò)期，如果過(guò)期則會(huì)刪除對(duì)應(yīng)的 key 。

如果過(guò)期鍵是主庫(kù)創(chuàng)建的，那么從庫(kù)進(jìn)行檢查是不會(huì)進(jìn)行刪除操作的,只是會(huì)根據(jù) key 的過(guò)期時(shí)間返回過(guò)期或者未過(guò)期的狀態(tài)。

3、定期刪除

定期刪除是對(duì)上面兩種刪除策略的一種整合和折中

每個(gè)一段時(shí)間就對(duì)一些 key 進(jìn)行采樣檢查，檢查是否過(guò)期，如果過(guò)期就進(jìn)行刪除

1、采樣一定個(gè)數(shù)的key，采樣的個(gè)數(shù)可以進(jìn)行配置，并將其中過(guò)期的 key 全部刪除；

2、如果過(guò)期 key 的占比超過(guò)可接受的過(guò)期 key 的百分比，則重復(fù)刪除的過(guò)程，直到過(guò)期key的比例降至可接受的過(guò)期 key 的百分比以下。

優(yōu)點(diǎn)：

定期刪除，通過(guò)控制定期刪除執(zhí)行的時(shí)長(zhǎng)和頻率，可以減少刪除操作對(duì) CPU 的影響，同時(shí)也能較少因過(guò)期鍵帶來(lái)的內(nèi)存的浪費(fèi)。

缺點(diǎn)：

執(zhí)行的頻率不太好控制

頻率過(guò)快對(duì) CPU 不友好，如果過(guò)慢了就會(huì)對(duì)內(nèi)存不太友好，過(guò)期的鍵值對(duì)不能及時(shí)的被刪除掉

同時(shí)如果一個(gè)鍵值對(duì)過(guò)期了，但是沒(méi)有被刪除，這時(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)鍵過(guò)期，調(diào)整大小，重哈希。
void databasesCron(void) {
    // 通過(guò)隨機(jī)抽樣來(lái)過(guò)期
    // 這里區(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,
    // 可接受的過(guò)期 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 過(guò)期時(shí)積累一些全局統(tǒng)計(jì)信息，以便了解邏輯上已經(jīng)過(guò)期但仍存在于數(shù)據(jù)庫(kù)中的 key 的數(shù)量
    long total_sampled = 0;
    long total_expired = 0;

    for (j = 0; j < dbs_per_call && timelimit_exit == 0; j++) {
        ...
        // 如果超過(guò) config_cycle_acceptable_stale 的key過(guò)期了，則重復(fù)刪除的過(guò)程，直到過(guò)期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;
                        // 過(guò)期檢查，并對(duì)過(guò)期鍵進(jìn)行刪除
                        if (activeExpireCycleTryExpire(db,e,now)) expired++;
                        ...
                    }
                }
                db->expires_cursor++;
            }
         ...
        // 判斷過(guò)期 key 的占比是否大于 config_cycle_acceptable_stale，如果大于持續(xù)進(jìn)行過(guò)期 key 的刪除
        } while (sampled == 0 ||
                 (expired*100/sampled) > config_cycle_acceptable_stale);
    }
    ...
}

// 檢查刪除由從節(jié)點(diǎn)創(chuàng)建的有過(guò)期的時(shí)間的 key 
void expireSlaveKeys(void) {
    // 從主庫(kù)同步的 key，過(guò)期時(shí)間由主庫(kù)維護(hù)，主庫(kù)同步 DEL 操作到從庫(kù)。
    // 從庫(kù)如果是 READ-WRITE 模式，就可以繼續(xù)寫(xiě)入數(shù)據(jù)。從庫(kù)自己寫(xiě)入的數(shù)據(jù)就需要自己來(lái)維護(hù)其過(guò)期操作。
    if (slaveKeysWithExpire == NULL ||
        dictSize(slaveKeysWithExpire) == 0) return;
     ...
}

惰性刪除過(guò)程

1、固定的時(shí)間執(zhí)行一次定期刪除；

2、采樣一定個(gè)數(shù)的key，采樣個(gè)數(shù)可以進(jìn)行配置，并將其中過(guò)期的key全部刪除；

3、如果過(guò)期 key 的占比超過(guò)可接受的過(guò)期 key 的百分比，則重復(fù)刪除的過(guò)程，直到過(guò)期key的比例降至可接受的過(guò)期 key 的百分比以下；

4、對(duì)于從庫(kù)創(chuàng)建的過(guò)期 key 同樣從庫(kù)是不能進(jìn)行刪除的。

Redis 中過(guò)期刪除策略

上面討論的三種策略，都有或多或少的問(wèn)題。Redis 中實(shí)際采用的策略是惰性刪除加定期刪除的組合方式。

組合方式的使用

定期刪除，獲取 CPU 和 內(nèi)存的使用平衡，針對(duì)過(guò)期的 KEY 可能得不到及時(shí)的刪除，當(dāng) KEY 被再次獲取的時(shí)候，通過(guò)惰性刪除再做一次過(guò)期檢查，來(lái)避免業(yè)務(wù)獲取到過(guò)期內(nèi)容。

從庫(kù)是否會(huì)臟讀主庫(kù)創(chuàng)建的過(guò)期鍵

從上面惰性刪除和定期刪除的源碼閱讀中，我們可以發(fā)現(xiàn)，從庫(kù)對(duì)于主庫(kù)的過(guò)期鍵是不能主動(dòng)進(jìn)行刪除的。如果一個(gè)主庫(kù)創(chuàng)建的過(guò)期鍵值對(duì)，已經(jīng)過(guò)期了，主庫(kù)在進(jìn)行定期刪除的時(shí)候，沒(méi)有及時(shí)的刪除掉，這時(shí)候從庫(kù)請(qǐng)求了這個(gè)鍵值對(duì)，當(dāng)執(zhí)行惰性刪除的時(shí)候，因?yàn)槭侵鲙?kù)創(chuàng)建的鍵值對(duì)，這時(shí)候是不能在從庫(kù)中刪除的，那么是不是就意味著從庫(kù)會(huì)讀取到已經(jīng)過(guò)期的數(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ì)這一問(wèn)題的描述

大概意思就是從節(jié)點(diǎn)不會(huì)主動(dòng)刪除過(guò)期鍵，從節(jié)點(diǎn)會(huì)等待主節(jié)點(diǎn)觸發(fā)鍵過(guò)期。當(dāng)主節(jié)點(diǎn)觸發(fā)鍵過(guò)期時(shí)，主節(jié)點(diǎn)會(huì)同步一個(gè)del命令給所有的從節(jié)點(diǎn)。

因?yàn)槭侵鞴?jié)點(diǎn)驅(qū)動(dòng)刪除的，所以從節(jié)點(diǎn)會(huì)獲取到已經(jīng)過(guò)期的鍵值對(duì)。從節(jié)點(diǎn)需要根據(jù)自己本地的邏輯時(shí)鐘來(lái)判斷減值是否過(guò)期，從而實(shí)現(xiàn)數(shù)據(jù)集合的一致性讀操作。

我們知道 Redis 中的過(guò)期策略是惰性刪除和定期刪除，所以每個(gè)鍵值的操作，都會(huì)使用惰性刪除來(lái)檢查是否過(guò)期，然后判斷是否可以進(jìn)行刪除

// https://github.com/redis/redis/blob/6.2/src/db.c#L1541
// 當(dāng)訪問(wèn)到 key 的時(shí)候，會(huì)調(diào)用這個(gè)函數(shù)，因?yàn)橛械?nbsp;key 雖然已經(jīng)過(guò)期了，但是還可能存在于內(nèi)存中

// key 仍然有效，函數(shù)返回值為0，否則，如果 key 過(guò)期，函數(shù)返回1。
int expireIfNeeded(redisDb *db, robj *key) {
    // 檢查 key 是否過(guò)期
    if (!keyIsExpired(db,key)) return 0;

    // 從庫(kù)的過(guò)期是主庫(kù)控制的，是不會(huì)進(jìn)行刪除操作的
    // 上面已經(jīng)判斷過(guò)是否到期了，所以這里的 key 肯定設(shè)計(jì)過(guò)期的 key ,不過(guò)如果是主節(jié)點(diǎn)創(chuàng)建的 key 從節(jié)點(diǎn)就不刪除，只會(huì)返回已經(jīng)過(guò)期了
    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) {
    // 過(guò)期時(shí)間
    mstime_t when = getExpire(db,key);
    mstime_t now;

    // 沒(méi)有過(guò)期
    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í)行的過(guò)程中不過(guò)期
    if (server.lua_caller) {
        now = server.lua_time_snapshot;
    }
    // 如果我們正在執(zhí)行一個(gè)命令，我們?nèi)匀幌Ｍ褂靡粋€(gè)不會(huì)改變的引用時(shí)間:在這種情況下，我們只使用緩存的時(shí)間，我們?cè)诿看握{(diào)用call()函數(shù)之前更新。
    // 這樣我們就避免了RPOPLPUSH之類(lèi)的命令，這些命令可能會(huì)重新打開(kāi)相同的鍵多次，如果下次調(diào)用會(huì)看到鍵過(guò)期，則會(huì)使已經(jīng)打開(kāi)的對(duì)象在下次調(diào)用中失效，而第一次調(diào)用沒(méi)有。
    else if (server.fixed_time_expire > 0) {
        now = server.mstime;
    }
    // 其他情況下，獲取最新的時(shí)間
    else {
        now = mstime();
    }
    // 判斷是否過(guò)期了
    return now > when;
}

// 返回指定 key 的過(guò)期時(shí)間，如果沒(méi)有過(guò)期則返回-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)建的過(guò)期 key ，雖然不能進(jìn)行刪除的操作，但是可以進(jìn)行過(guò)期時(shí)間的判斷，所以如果主庫(kù)創(chuàng)建的過(guò)期鍵，如果主庫(kù)沒(méi)有及時(shí)進(jìn)行刪除，這時(shí)候從庫(kù)可以通過(guò)惰性刪除來(lái)判斷鍵值對(duì)的是否過(guò)期，避免讀取到過(guò)期的內(nèi)容。

內(nèi)存淘汰機(jī)制

上面我們討論的 Redis 過(guò)期策略指的是 Redis 使用那種策略，來(lái)刪除已經(jīng)過(guò)期的鍵值對(duì)。但是有一些 key以后永遠(yuǎn)用不到了，那么就可能一直不能被刪除掉，還有就是 Redis 中的使用過(guò)程中，隨著寫(xiě)數(shù)據(jù)的增加，Redis 中的內(nèi)存不夠用了，這時(shí)候就需要 Redis 的內(nèi)存淘汰策略了。

Redis 過(guò)期策略指的是 Redis 使用那種策略，來(lái)刪除已經(jīng)過(guò)期的鍵值對(duì)；

Redis 內(nèi)存淘汰機(jī)制指的是，當(dāng) Redis 運(yùn)行內(nèi)存已經(jīng)超過(guò) Redis 設(shè)置的最大內(nèi)存之后，將采用什么策略來(lái)刪除符合條件的鍵值對(duì)，以此來(lái)保障 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中，通過(guò)參數(shù) maxmemory <bytes> 來(lái)設(shè)置

查詢(xún)最大運(yùn)行內(nèi)存

127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "0"

在 64 位操作系統(tǒng)中，當(dāng) maxmemory 為 0 時(shí)，表示沒(méi)有內(nèi)存大小限制，32位的系統(tǒng)。

有哪些內(nèi)存淘汰策略

當(dāng)現(xiàn)有內(nèi)存大于 maxmemory 時(shí)，便會(huì)觸發(fā)redis主動(dòng)淘汰內(nèi)存方式，通過(guò)設(shè)置 maxmemory-policy ，有如下幾種淘汰方式：

1、volatile-lru:淘汰所有設(shè)置了過(guò)期時(shí)間的鍵值中最久未使用的鍵值；

2、allkeys-lru:淘汰整個(gè)鍵值中最久未使用的鍵值；

3、volatile-random:隨機(jī)淘汰設(shè)置了過(guò)期時(shí)間的任意鍵值；

4、allkeys-random:隨機(jī)淘汰任意鍵值;

5、volatile-ttl:優(yōu)先淘汰更早過(guò)期的鍵值;

6、noeviction:不淘汰任何數(shù)據(jù)，當(dāng)內(nèi)存不足時(shí)，新增操作會(huì)報(bào)錯(cuò)，Redis 默認(rèn)內(nèi)存淘汰策略；

在 Redis 4.0 版本中又新增了 2 種淘汰策略：

volatile-lfu：淘汰所有設(shè)置了過(guò)期時(shí)間的鍵值中，最少使用的鍵值；

allkeys-lfu：淘汰整個(gè)鍵值中最少使用的鍵值。

其中 allkeys-xxx 表示從所有的鍵值中淘汰數(shù)據(jù)，而 volatile-xxx 表示從設(shè)置了過(guò)期鍵的鍵值中淘汰數(shù)據(jù)。

內(nèi)存淘汰算法

除了隨機(jī)刪除和不刪除之外，主要有兩種淘汰算法：LRU 算法和 LFU 算法。

LRU

LRU 全稱(chēng)是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è)額外的字段，用于記錄此鍵值的最后一次訪問(wèn)時(shí)間，Redis 內(nèi)存淘汰時(shí)，會(huì)使用隨機(jī)采樣的方式來(lái)淘汰數(shù)據(jù)，它是隨機(jī)取 5 個(gè)值（此值可配置），然后淘汰最久沒(méi)有使用的那個(gè)。

這里看下是如何實(shí)現(xiàn)的呢

Redis 在源碼中對(duì)于每個(gè)鍵值對(duì)中的值，會(huì)使用一個(gè) redisObject 結(jié)構(gòu)體來(lái)保存指向值的指針，這里先來(lái)看下 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，記錄訪問(wèn)的時(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ì)被訪問(wèn)的時(shí)候記錄的時(shí)間也會(huì)被更新，當(dāng)一個(gè)鍵值對(duì)被訪問(wèn)時(shí)，訪問(wèn)操作最終都會(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)建和訪問(wèn)一個(gè)鍵值對(duì)的代碼，每次操作，redisObject 中記錄的 lru 時(shí)間就會(huì)被同步的更新

Redis 會(huì)判斷當(dāng)前內(nèi)存的使用情況，如果超過(guò)了 maxmemory 配置的值，就會(huì)觸發(fā)新的內(nèi)存淘汰了

如果內(nèi)存超過(guò)了 maxmemory 的值，這時(shí)候還需要去計(jì)算需要釋放的內(nèi)存量，這個(gè)釋放的內(nèi)存大小等于已使用的內(nèi)存量減去 maxmemory。不過(guò)，已使用的內(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è)置了過(guò)期時(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;
                    }
                }
                ...
            }
        }
    ...
}

// 用來(lái)填充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，用來(lái)保存待淘汰的候選鍵值對(duì)。這個(gè)數(shù)組的元素類(lèi)型是 evictionPoolEntry 結(jié)構(gòu)體，該結(jié)構(gòu)體保存了待淘汰鍵值對(duì)的空閑時(shí)間 idle、對(duì)應(yīng)的 key 等信息。

可以看到上面的上面會(huì)選取一定的過(guò)期鍵，然后插入到 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;

然后通過(guò) evictionPoolPopulate 函數(shù)，進(jìn)行采樣，然后將采樣數(shù)據(jù)寫(xiě)入到 EvictionPoolLRU 中，插入到 EvictionPoolLRU 中的數(shù)據(jù)是按照空閑時(shí)間從小到大進(jìn)行排好序的

freeMemoryIfNeeded 函數(shù)會(huì)遍歷一次 EvictionPoolLRU 數(shù)組，從數(shù)組的最后一個(gè) key 開(kāi)始選擇，如果選到的 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開(kāi)始查找
                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);
            ...
        }
    }
    ...
}

每次選中一部分過(guò)期的鍵值對(duì)，每次淘汰最久沒(méi)有使用的那個(gè)，如果釋放的內(nèi)存空間還不夠，就會(huì)重復(fù)的進(jìn)行采樣，刪除的過(guò)程。

LFU

除了 LRU 算法，Redis 在 4.0 版本引入了 LFU 算法，就是最不頻繁使用（Least Frequently Used，LFU）算法。

LRU 算法：淘汰最近最少使用的數(shù)據(jù)，它是根據(jù)時(shí)間維度來(lái)選擇將要淘汰的元素，即刪除掉最長(zhǎng)時(shí)間沒(méi)被訪問(wèn)的元素。

LFU 算法：淘汰最不頻繁訪問(wèn)的數(shù)據(jù)，它是根據(jù)頻率維度來(lái)選擇將要淘汰的元素，即刪除訪問(wèn)頻率最低的元素。如果兩個(gè)元素的訪問(wèn)頻率相同，則淘汰最久沒(méi)被訪問(wèn)的元素。

LFU 的基本原理

LFU（Least Frequently Used）算法，即最少訪問(wèn)算法，根據(jù)訪問(wèn)緩存的歷史頻率來(lái)淘汰數(shù)據(jù)，核心思想是“如果數(shù)據(jù)在過(guò)去一段時(shí)間被訪問(wèn)的次數(shù)很少，那么將來(lái)被訪問(wèn)的概率也會(huì)很低”。

它是根據(jù)頻率維度來(lái)選擇將要淘汰的元素，即刪除訪問(wèn)頻率最低的元素。如果兩個(gè)元素的訪問(wèn)頻率相同，則淘汰最久沒(méi)被訪問(wèn)的元素。也就是說(shuō) LFU 淘汰的時(shí)候會(huì)選擇兩個(gè)維度，先比較頻率，選擇訪問(wèn)頻率最小的元素；如果頻率相同，則按時(shí)間維度淘汰掉最久遠(yuǎn)的那個(gè)元素。

LUF 的實(shí)現(xiàn)可參見(jiàn)LFU實(shí)現(xiàn)詳解

這看下 Redis 中對(duì) LFU 算法的實(shí)現(xiàn)

1、鍵值對(duì)的訪問(wèn)頻率記錄和更新

上面分析 LRU 的時(shí)候，聊到了 redisObject，Redis 在源碼中對(duì)于每個(gè)鍵值對(duì)中的值，會(huì)使用一個(gè) redisObject 結(jié)構(gòu)體來(lái)保存指向值的指針。里面 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，記錄訪問(wèn)的時(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ì)的訪問(wèn)時(shí)間戳和訪問(wèn)次數(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í)間戳和訪問(wèn)次數(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ì)被訪問(wèn)時(shí)，Redis 會(huì)調(diào)用 lookupKey 函數(shù)進(jìn)行查找。當(dāng) maxmemory-policy 設(shè)置使用 LFU 算法時(shí)，lookupKey 函數(shù)會(huì)調(diào)用 updateLFU 函數(shù)來(lái)更新鍵值對(duì)的訪問(wèn)頻率，也就是 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ù)更新訪問(wèn)頻率
        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
/* 訪問(wèn)對(duì)象時(shí)更新 LFU。
 * 首先，如果達(dá)到遞減時(shí)間，則遞減計(jì)數(shù)器。
 * 然后對(duì)計(jì)數(shù)器進(jìn)行對(duì)數(shù)遞增，并更新訪問(wèn)時(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ì)的上一次訪問(wèn)時(shí)間
    unsigned long ldt = o->lru >> 8;
    // 獲取當(dāng)前的訪問(wèn)次數(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)前訪問(wèn)次數(shù)，那么，衰減后的訪問(wèn)次數(shù)是當(dāng)前訪問(wèn)次數(shù)減去衰減大小；否則，衰減后的訪問(wèn)次數(shù)等于0
        counter = (num_periods > counter) ? 0 : counter - num_periods;
    // 如果衰減大小為0，則返回原來(lái)的訪問(wèn)次數(shù)
    return counter;
}

上面的代碼可以看到，當(dāng)訪問(wèn)一個(gè)鍵值對(duì)的時(shí)候，首先進(jìn)行了訪問(wèn)次數(shù)的衰減？

LFU 算法是根據(jù)訪問(wèn)頻率來(lái)淘汰數(shù)據(jù)的，而不只是訪問(wèn)次數(shù)。如果訪問(wèn)間隔時(shí)間越長(zhǎng)，那么訪問(wèn)頻率就越低。

因?yàn)?Redis 是使用 lru 變量中的訪問(wèn)次數(shù)來(lái)表示訪問(wèn)頻率，所以在每次更新鍵值對(duì)的訪問(wèn)頻率時(shí)，就會(huì)通過(guò) LFUDecrAndReturn 函數(shù)對(duì)訪問(wèn)次數(shù)進(jìn)行衰減。

LFUDecrAndReturn 函數(shù)會(huì)調(diào)用 LFUTimeElapsed 函數(shù)（在 evict.c 文件中），計(jì)算距離鍵值對(duì)的上一次訪問(wèn)已經(jīng)過(guò)去的時(shí)長(zhǎng)。這個(gè)時(shí)長(zhǎng)也是以 1 分鐘為精度來(lái)計(jì)算的。有了距離上次訪問(wèn)的時(shí)長(zhǎng)后，LFUDecrAndReturn 函數(shù)會(huì)把這個(gè)時(shí)長(zhǎng)除以 lfu_decay_time 的值，并把結(jié)果作為訪問(wèn)次數(shù)的衰減大小。

lfu_decay_time 變量值，是由 redis.conf 文件中的配置項(xiàng) lfu-decay-time 來(lái)決定的。Redis 在初始化時(shí)，會(huì)通過(guò) initServerConfig 函數(shù)來(lái)設(shè)置 lfu_decay_time 變量的值，默認(rèn)值為 1。所以，在默認(rèn)情況下，訪問(wèn)次數(shù)的衰減大小就是等于上一次訪問(wèn)距離當(dāng)前的分鐘數(shù)。

衰減之后，再來(lái)看下如何進(jìn)行訪問(wè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)前訪問(wèn)次數(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)前訪問(wèn)次數(shù)小于255的時(shí)候，每次 LFULogIncr 函數(shù)會(huì)計(jì)算一個(gè)閾值 p，以及一個(gè)取值為 0 到 1 之間的隨機(jī)概率值 r。如果概率 r 小于閾值 p，那么 LFULogIncr 函數(shù)才會(huì)將訪問(wèn)次數(shù)加 1。否則的話，LFULogIncr 函數(shù)會(huì)返回當(dāng)前的訪問(wèn)次數(shù)，不做更新。

這樣按照一定的概率增加訪問(wèn)頻率，避免了訪問(wèn)次數(shù)過(guò)大，8 bits 計(jì)數(shù)器對(duì)訪問(wèn)次數(shù)的影響。

2、使用 LFU 算法淘汰數(shù)據(jù)

LFU 處理數(shù)據(jù)淘汰和 LRU 方式差不多，這里回顧下 LRU 處理數(shù)據(jù)淘汰的過(guò)程

• 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ù)中，使用了不同的方法來(lái)計(jì)算每個(gè)待淘汰鍵值對(duì)的空閑時(shí)間。

LRU 中 idle 記錄的是它距離上次訪問(wèn)的空閑時(shí)間。

LFU 中 idle 記錄的是用 255 減去鍵值對(duì)的訪問(wèn)次數(shù)。也就是鍵值對(duì)訪問(wèn)次數(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í)，它就能選出訪問(wèn)次數(shù)小的鍵值對(duì)了，也就是把訪問(wèn)頻率低的鍵值對(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 缺不能拿來(lái)用，會(huì)造成資源的浪費(fèi)。

為什么會(huì)產(chǎn)生內(nèi)存碎片呢？

內(nèi)存碎片如何產(chǎn)生

1、內(nèi)存分配器的分配策略

內(nèi)存分配器對(duì)于內(nèi)存的分配，一般是按固定大小來(lái)分配內(nèi)存，而不是完全按照應(yīng)用程序申請(qǐng)的內(nèi)存空間大小給程序分配。

Redis 可以使用 libc、jemalloc、tcmalloc 多種內(nèi)存分配器來(lá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)用還要寫(xiě)入 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ì)把空間釋放出來(lái)，形成空閑空間。

Redis中的值刪除的時(shí)候，并沒(méi)有把內(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 中有部分自己沒(méi)在用，卻不釋放的內(nèi)存，導(dǎo)致了內(nèi)存碎片的發(fā)生。

碎片率的意義

mem_fragmentation_ratio的不同值，說(shuō)明不同的情況。

• 大于1：說(shuō)明內(nèi)存有碎片，一般在1到1.5之間是正常的；

• 大于1.5：說(shuō)明內(nèi)存碎片率比較大，需要考慮是否要進(jìn)行內(nèi)存碎片清理，要引起重視；

• 小于1：說(shuō)明已經(jīng)開(kāi)始使用交換內(nèi)存，也就是使用硬盤(pán)了，正常的內(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ì)將沒(méi)用的內(nèi)存歸還給操作系統(tǒng)，碎片率會(huì)降下來(lái)；

4.0 版本的 Redis 引入了自動(dòng)內(nèi)存碎片清理的功能。

自動(dòng)碎片清理，只要設(shè)置了如下的配置，內(nèi)存就會(huì)自動(dòng)清理了。

config set activedefrag yes

不過(guò)對(duì)于具體什么時(shí)候開(kāi)始，受下面兩個(gè)參數(shù)的控制，只要一個(gè)不滿足就停止自動(dòng)清理

• active-defrag-ignore-bytes 100mb：表示內(nèi)存碎片的字節(jié)數(shù)達(dá)到100MB時(shí)，開(kāi)始清理；

• active-defrag-threshold-lower 10：表示內(nèi)存碎片空間占操作系統(tǒng)分配給Redis的總空間比例達(dá)到10%時(shí)，開(kāi)始清理。

為了保證清理過(guò)程中對(duì) CPU 的影響，還設(shè)置了兩個(gè)參數(shù)，分別用于控制清理操作占用的CPU時(shí)間比例的上、下限，既保證清理工作能正常進(jìn)行，又避免了降低Redis性能。

• active-defrag-cycle-min 25： 表示自動(dòng)清理過(guò)程所用CPU時(shí)間的比例不低于25%，保證清理能正常開(kāi)展；

• active-defrag-cycle-max 75：表示自動(dòng)清理過(guò)程所用CPU時(shí)間的比例不高于75%，一旦超過(guò)，就停止清理，從而避免在清理時(shí)，大量的內(nèi)存拷貝阻塞Redis，導(dǎo)致響應(yīng)延遲升高。 、

如果你對(duì)自動(dòng)清理的效果不滿意，可以使用如下命令，直接試下手動(dòng)碎片清理：

memory purge

以上就是關(guān)于“Redis中過(guò)期鍵怎么刪除”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。