作者 | KL博主

背景

摸清 Redis 的數(shù)據(jù)清理策略，給內(nèi)存使用高的被動(dòng)緩存場(chǎng)景，在遇到內(nèi)存不足時(shí)，怎么做是最優(yōu)解提供決策依據(jù)。?

本文整理 Redis 的數(shù)據(jù)清理策略所有代碼來(lái)自 Redis version ：5.0， 不同版本的 Redis 策略可能有調(diào)整

清理策略

Redis 的清理策略，總結(jié)概括為三點(diǎn)，被動(dòng)清理、定時(shí)清理、驅(qū)逐清理

被動(dòng)清理

訪問(wèn) Key 時(shí)，每次都會(huì)檢查該 Key 是否已過(guò)期，如果過(guò)期則刪除該 Key ，get 、scan 等指令都會(huì)觸發(fā) Key 的過(guò)期檢查。

關(guān)鍵代碼如下， expireIfNeeded (redisDb *db, robj *key) 函數(shù)會(huì)觸發(fā)檢查并刪除

robj *lookupKeyReadWithFlags(redisDb *db, robj *key, int flags) {
    robj *val;

    if (expireIfNeeded(db,key) == 1) {
        /* Key expired. If we are in the context of a master, expireIfNeeded()
         * returns 0 only when the key does not exist at all, so it's safe
         * to return NULL ASAP. */
        if (server.masterhost == NULL) {
            server.stat_keyspace_misses++;
            return NULL;
        }
        if (server.current_client &&
            server.current_client != server.master &&
            server.current_client->cmd &&
            server.current_client->cmd->flags & CMD_READONLY)
        {
            server.stat_keyspace_misses++;
            return NULL;
        }
    }
    val = lookupKey(db,key,flags);
    if (val == NULL)
        server.stat_keyspace_misses++;
    else
        server.stat_keyspace_hits++;
    return val;
}

定時(shí)清理

通過(guò) serverCron 定期觸發(fā)清理，可以通過(guò) hz 參數(shù)，配置每秒執(zhí)行多少次清理任務(wù)，流程如下

1、Redis 配置項(xiàng) hz 定義了 serverCron 任務(wù)的執(zhí)行周期，默認(rèn)為 10，即 CPU 空閑時(shí)每秒執(zhí)行 10 次

2、每次過(guò)期 Key 清理的 timelimit 不超過(guò) CPU 時(shí)間的 25% ，即若 hz = 1，則一次清理時(shí)間最大為 250ms，若 hz = 10，則一次清理時(shí)間最大為 25ms，計(jì)算邏輯（timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;）

3、清理時(shí)依次遍歷所有的 db;

4、從 db 中隨機(jī)取 20 個(gè) key，判斷是否過(guò)期，若過(guò)期，則逐出；

5、若有 5 個(gè)以上 key 過(guò)期，則重復(fù)步驟 4，否則遍歷下一個(gè) db;

6、在清理過(guò)程中，若達(dá)到了 timelimit 時(shí)間，退出清理過(guò)程；

關(guān)鍵代碼如下，activeExpireCycle (int type) 會(huì)執(zhí)行上述邏輯

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
    ...
    databasesCron();
    ...
}

void databasesCron(void) {
    /* Expire keys by random sampling. Not required for slaves
     * as master will synthesize DELs for us. */
    if (server.active_expire_enabled) {
        if (server.masterhost == NULL) {
            activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW);
        } else {
            expireSlaveKeys();
        }
    }
    ...
}

驅(qū)逐清理

Redis 在命令處理函數(shù) processCommand 會(huì)進(jìn)行內(nèi)存的檢查和驅(qū)逐，任何命令都會(huì)出觸發(fā)，包括 ping 命令。

如果配置了 maxmemory ，且當(dāng)前內(nèi)存超過(guò) maxmemory 時(shí)，則會(huì)執(zhí)行 maxmemory_policy 篩選出需要清理的 Key，繼而判斷 lazyfree-lazy-eviction 是否開(kāi)啟來(lái)進(jìn)行 Key 的同步還是異步刪除。無(wú)論是同步刪除還是異步刪除，最后都會(huì)繼續(xù)校驗(yàn)內(nèi)存是否超限，直到內(nèi)存低于 maxmemory。驅(qū)逐只會(huì)在 Master 節(jié)點(diǎn)進(jìn)行。

maxmemory_policy 可選如下：

volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選【最近最少使用】的 Key 進(jìn)行刪除

volatile-ttl：從己設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選【將要過(guò)期】的 Key 進(jìn)行刪除

volatile-lfu：從己設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中選擇【最不常用】的 Key 進(jìn)行刪除

volatile-random：從己設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中【任意選擇】Key 進(jìn)行刪除

allkeys-lru：從數(shù)據(jù)集中挑選【最近最少使用】的 Key 進(jìn)行刪除

allkeys-lfu：從數(shù)據(jù)集中【優(yōu)先刪除掉最不常用】的 Key

allkeys-random：從數(shù)據(jù)集中【任意選擇】 Key 進(jìn)行刪除

no-enviction：禁止驅(qū)逐數(shù)據(jù)

如上圖，6.2 后的版本支持通過(guò)逐出因子 maxmemory-eviction-tenacity 來(lái)控制逐出阻塞的時(shí)間。具體的阻塞耗時(shí)間可以通過(guò) latency-monitor 里的?eviction-cycle、eviction-del?來(lái)觀測(cè)。 關(guān)鍵代碼如下，freeMemoryIfNeeded () 函數(shù)會(huì)執(zhí)行上述邏輯

int processCommand(client *c) {
 ...
  if (server.maxmemory && !server.lua_timedout) {
        int out_of_memory =  freeMemoryIfNeededAndSafe() == C_ERR;
        ...
  }
 ...
}

int freeMemoryIfNeededAndSafe(void) {
    if (server.lua_timedout || server.loading) return C_OK;
    return freeMemoryIfNeeded();
}

ps: 當(dāng)觸發(fā) aof 文件重寫(xiě)，fork 操作會(huì)阻塞主進(jìn)程，此時(shí)積壓的指令需要的內(nèi)存，在 fork 結(jié)束后，需要一次性 eviction 出來(lái)，這時(shí)的 eviction-cycle 耗時(shí)會(huì)惡化的很?chē)?yán)重，達(dá)到秒級(jí)的阻塞，此時(shí)可通過(guò) latency-monitor 觀測(cè) eviction-cycle 、fork 總是成對(duì)出現(xiàn)。

總結(jié)

回到開(kāi)篇的背景問(wèn)題，當(dāng)遇到內(nèi)存使用高的被動(dòng)緩存場(chǎng)景，可用內(nèi)存不足時(shí)：

離線分析內(nèi)存，是否存在大量【已過(guò)期】的內(nèi)存來(lái)不及定時(shí)清理，此時(shí)可調(diào)大 hz 參數(shù)來(lái)加速過(guò)期內(nèi)存的主動(dòng)清理。hz 參數(shù)最大 500 ，不過(guò)要觀察 CPU 的影響，不要因?yàn)?hz 影響讀寫(xiě)流量

如果調(diào)整 hz 還是沒(méi)法及時(shí)清理已過(guò)期的內(nèi)存，則可以使用 scan 指令來(lái)被動(dòng)訪問(wèn) key 的方式手動(dòng)刪除，注意執(zhí)行 scan 時(shí)的 count ，同時(shí)觀測(cè) CPU 使用情況，scan 的 count 越大，CPU 消耗會(huì)越高，完成一次 sacn 刪除的時(shí)間最快。為了減少對(duì)線上的影響，可以在業(yè)務(wù)低峰期，周期性的執(zhí)行。

通過(guò) latency-monitor 觀測(cè) eviction-cycle、eviction-del 指標(biāo)，是否因內(nèi)存驅(qū)逐阻塞嚴(yán)重，可開(kāi)啟 lazyfree-lazy-eviction 來(lái)緩解阻塞。

業(yè)務(wù)上可以考慮關(guān)閉 aof 的影響，關(guān)閉 aof 可以減少驅(qū)逐清理 eviction-cycle 延遲帶來(lái)的讀寫(xiě)超時(shí)影響。

可升級(jí)到 7.x 版本的 Redis ，通過(guò) maxmemory-eviction-tenacity 參數(shù)主動(dòng)控制每次驅(qū)逐的阻塞時(shí)間

如果還是很慢，可考慮升級(jí)內(nèi)存規(guī)格

編輯：黃飛

?