Redis 源码解读之逐出策略

背景和问题

本文想解决的问题:

  1. redis 触发逐出的时机是怎样的?
  2. redis 逐出策略有哪些?
  3. 如何在海量的 key 中快速找到逐出评价值(idle)最高的key,并将之逐出?
  4. LFU 算法的频率是如何统计的?

结论

  1. redis 触发逐出的时机是怎样的?

如图,主要有两个地方会触发逐出。

  • 更新 maxmemory 参数,导致实际使用内存大于该限制。
  • 处理客户端请求,使用到的内存大于内存限制。

  1. redis 逐出策略有哪些?
  • 逐出策略主要分为两个维度:四种逐出 key 的算法和两种逐出 key 的范围。这两个维度叉乘的集合,去除 allkeys-ttl, 加上一个不逐出的策略,就是redis 支持的所有逐出策略。

    • 逐出 key 的算法:LRU,LFU,随机逐出(random)和根据 TTL 逐出(ttl)。
    • 逐出 key 的范围: 所有 key 都能被逐出(allkeys) 和 有过期时间的 key 才能被逐出(volatile)
  • noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used (most write commands, but DEL and a few more exceptions).

  • allkeys-lru: evict keys by trying to remove the less recently used (LRU) keys first, in order to make space for the new data added.

  • volatile-lru: evict keys by trying to remove the less recently used (LRU) keys first, but only among keys that have an expire set, in order to make space for the new data added.

  • allkeys-random: evict keys randomly in order to make space for the new data added.

  • volatile-random: evict keys randomly in order to make space for the new data added, but only evict keys with an expire set.

  • volatile-ttl: evict keys with an expire set, and try to evict keys with a shorter time to live (TTL) first, in order to make space for the new data added.

  • volatile-lfu: Evict using approximated LFU among the keys with an expire set.

  • allkeys-lfu: Evict any key using approximated LFU.

  1. 如何在海量的 key 中快速找到逐出评价值(idle)最高的key,并将之逐出?

抽样逐出:每次从数据中抽取 server.maxmemory_samples 个元素插入以 idle 值为优先级的优先队列 EvictionPoolLRU。每轮逐出优先队列的第一个 key。

/* To improve the quality of the LRU approximation we take a set of keys
* that are good candidate for eviction across freeMemoryIfNeeded() calls.
*
* Entries inside the eviction pool are taken ordered by idle time, putting
* greater idle times to the right (ascending order).
*
* When an LFU policy is used instead, a reverse frequency indication is used
* instead of the idle time, so that we still evict by larger value (larger
* inverse frequency means to evict keys with the least frequent accesses).
*
* Empty entries have the key pointer set to NULL. */
#define EVPOOL_SIZE 16
#define EVPOOL_CACHED_SDS_SIZE 255
struct evictionPoolEntry {
unsigned long long idle; /* Object idle time (inverse frequency for LFU) >*/
sds key; /* Key name. */
sds cached; /* Cached SDS object for key name. */
int dbid; /* Key DB number. */
}; static struct evictionPoolEntry *EvictionPoolLRU;
  1. LFU 算法的频率是如何统计的?
  • redis 对象的定义如下
#define LRU_BITS 24
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
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;
  • 其中 lru 字段用于计算逐出评价值 idle。在 LFU 算法中,lru 字段作为 LFU 统计的频率。
   // 根据不同的逐出策略, 计算出对应的逐出优先级数值(idle)
/* Calculate the idle time according to the policy. This is called
* idle just because the code initially handled LRU, but is in fact
* just a score where an higher score means better candidate. */
if (server.maxmemory_policy & MAXMEMORY_FLAG_LRU) {
idle = estimateObjectIdleTime(o);
} else if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
/* When we use an LRU policy, we sort the keys by idle time
* so that we expire keys starting from greater idle time.
* However when the policy is an LFU one, we have a frequency
* estimation, and we want to evict keys with lower frequency
* first. So inside the pool we put objects using the inverted
* frequency subtracting the actual frequency to the maximum
* frequency of 255. */
idle = 255-LFUDecrAndReturn(o);
} else if (server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL) {
/* In this case the sooner the expire the better. */
idle = ULLONG_MAX - (long)dictGetVal(de);
} else {
serverPanic("Unknown eviction policy in evictionPoolPopulate()");
}
  • lru 统计 LFU 频率时,作为分为两部分,第一部分(16 位)作为记录上次计数减少的时间戳。第二部分(8位)作为频率计数器(通过对数函数归一化,具体原理见 morris)。
           16 bits      8 bits
    +----------------+--------+
    + Last decr time | LOG_C |
    +----------------+--------+
  • 频率计数增加/减少
/* Logarithmically increment a counter. The greater is the current counter value
* the less likely is that it gets really implemented. Saturate it at 255. */
uint8_t LFULogIncr(uint8_t counter) {
if (counter == 255) return 255;
double r = (double)rand()/RAND_MAX;
double baseval = counter - LFU_INIT_VAL;
if (baseval < 0) baseval = 0;
double p = 1.0/(baseval*server.lfu_log_factor+1);
if (r < p) counter++;
return counter;
} /* If the object decrement time is reached decrement the LFU counter but
* do not update LFU fields of the object, we update the access time
* and counter in an explicit way when the object is really accessed.
* And we will times halve the counter according to the times of
* elapsed time than server.lfu_decay_time.
* Return the object frequency counter.
*
* This function is used in order to scan the dataset for the best object
* to fit: as we check for the candidate, we incrementally decrement the
* counter of the scanned objects if needed. */
unsigned long LFUDecrAndReturn(robj *o) {
unsigned long ldt = o->lru >> 8;
unsigned long counter = o->lru & 255;
unsigned long num_periods = server.lfu_decay_time ? >LFUTimeElapsed(ldt) / server.lfu_decay_time : 0;
if (num_periods)
counter = (num_periods > counter) ? 0 : counter - num_periods;
return counter;
}

源码概览

额…… Q&A 都介绍得差不多了。简单来说,就是 freeMemoryIfNeeded 函数。

/* This is an helper function for freeMemoryIfNeeded(), it is used in order
* to populate the evictionPool with a few entries every time we want to
* expire a key. Keys with idle time smaller than one of the current
* keys are added. Keys are always added if there are free entries.
*
* We insert keys on place in ascending order, so keys with the smaller
* idle time are on the left, and keys with the higher idle time on the
* right. */ void evictionPoolPopulate(int dbid, dict *sampledict, dict *keydict, struct evictionPoolEntry *pool) {
//... ...
count = dictGetSomeKeys(sampledict,samples,server.maxmemory_samples);
//... ... // 根据不同的逐出策略, 计算出对应的逐出优先级数值(idle)
/* Calculate the idle time according to the policy. This is called
* idle just because the code initially handled LRU, but is in fact
* just a score where an higher score means better candidate. */
if (server.maxmemory_policy & MAXMEMORY_FLAG_LRU) {
idle = estimateObjectIdleTime(o);
} else if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {
/* When we use an LRU policy, we sort the keys by idle time
* so that we expire keys starting from greater idle time.
* However when the policy is an LFU one, we have a frequency
* estimation, and we want to evict keys with lower frequency
* first. So inside the pool we put objects using the inverted
* frequency subtracting the actual frequency to the maximum
* frequency of 255. */
idle = 255-LFUDecrAndReturn(o);
} else if (server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL) {
/* In this case the sooner the expire the better. */
idle = ULLONG_MAX - (long)dictGetVal(de);
} else {
serverPanic("Unknown eviction policy in evictionPoolPopulate()");
}
// ... ...
将抽取样本的逐出数据插入以 idle 为评价标准的优先队列 pool (长度为 EVPOOL_SIZE)...
//... ...
} /* This function is periodically called to see if there is memory to free
* according to the current "maxmemory" settings. In case we are over the
* memory limit, the function will try to free some memory to return back
* under the limit.
*
* The function returns C_OK if we are under the memory limit or if we
* were over the limit, but the attempt to free memory was successful.
* Otherwise if we are over the memory limit, but not enough memory
* was freed to return back under the limit, the function returns C_ERR. */
int freeMemoryIfNeeded(void) {
// ... ...
if (server.maxmemory_policy == MAXMEMORY_NO_EVICTION)
goto cant_free; /* We need to free memory, but policy forbids. */ while (mem_freed < mem_tofree) { // 杨领well注: 每轮逐出一个 bestkey
// ... ...
if (server.maxmemory_policy & (MAXMEMORY_FLAG_LRU|MAXMEMORY_FLAG_LFU) ||
server.maxmemory_policy == MAXMEMORY_VOLATILE_TTL)
{
//... ...
/* We don't want to make local-db choices when expiring keys,
* so to start populate the eviction pool sampling keys from
* every DB. */
for (i = 0; i < server.dbnum; i++) {
db = server.db+i;
// 杨领well注: MAXMEMORY_FLAG_ALLKEYS 代表所有 key 都可以逐出,
// 因此从存全量数据的 dict 选取待逐出的 key。 如果没有标记 MAXMEMORY_FLAG_ALLKEYS
// 则只能逐出有过期时间的 key,因此从过期 dict 中选取逐出 key
dict = (server.maxmemory_policy & MAXMEMORY_FLAG_ALLKEYS) ?
db->dict : db->expires;
if ((keys = dictSize(dict)) != 0) {
evictionPoolPopulate(i, dict, db->dict, pool);
total_keys += keys;
}
}
// ... ...
从 pool 保存的逐出样本中,抽取逐出评价数值(idle)最高的key进行逐出...
//... ...
}
else if (server.maxmemory_policy == MAXMEMORY_ALLKEYS_RANDOM ||
server.maxmemory_policy == MAXMEMORY_VOLATILE_RANDOM)
{
/* When evicting a random key, we try to evict a key for
* each DB, so we use the static 'next_db' variable to
* incrementally visit all DBs. */
for (i = 0; i < server.dbnum; i++) {
j = (++next_db) % server.dbnum;
db = server.db+j;
dict = (server.maxmemory_policy == MAXMEMORY_ALLKEYS_RANDOM) ?
db->dict : db->expires;
if (dictSize(dict) != 0) {
de = dictGetRandomKey(dict);
bestkey = dictGetKey(de);
bestdbid = j;
break;
}
}
}
/* Finally remove the selected key. */
if (bestkey) {
// ... ...
propagateExpire(db,keyobj,server.lazyfree_lazy_eviction);
// ... ...
if (server.lazyfree_lazy_eviction)
dbAsyncDelete(db,keyobj);
else
dbSyncDelete(db,keyobj);
// ... ...
}
}
cant_free:
/* We are here if we are not able to reclaim memory. There is only one
* last thing we can try: check if the lazyfree thread has jobs in queue
* and wait... */
if (result != C_OK) {
//... ...
while(bioPendingJobsOfType(BIO_LAZY_FREE)) { // 如果需要资源,且 lazy_free 队列有数据,就会阻塞在这里等待消费完成
if (getMaxmemoryState(NULL,NULL,NULL,NULL) == C_OK) {
result = C_OK;
break;
}
usleep(1000);
}
//... ...
}
}

扩展阅读

Redis 源码解读之逐出策略的更多相关文章

  1. redis源码解读--内存分配zmalloc

    目录 主要函数 void *zmalloc(size_t size) void *zcalloc(size_t size) void zrealloc(void ptr, size_t size) v ...

  2. (十)redis源码解读

    一.redis工作机制 redis是 单线程,所有命令(set,get等)都会加入到队列中,然后一个个执行. 二.为什么redis速度快? 1.基于内存 2.redis协议resp 简单.可读.效率高 ...

  3. php-msf 源码解读【转】

    php-msf: https://github.com/pinguo/php-msf 百度脑图 - php-msf 源码解读: http://naotu.baidu.com/file/cc7b5a49 ...

  4. 从koa-session源码解读session本质

    前言 Session,又称为"会话控制",存储特定用户会话所需的属性及配置信息.存于服务器,在整个用户会话中一直存在. 然而: session 到底是什么? session 是存在 ...

  5. AFNetworking 3.0 源码解读 总结(干货)(下)

    承接上一篇AFNetworking 3.0 源码解读 总结(干货)(上) 21.网络服务类型NSURLRequestNetworkServiceType 示例代码: typedef NS_ENUM(N ...

  6. AFNetworking 3.0 源码解读(八)之 AFImageDownloader

    AFImageDownloader 这个类对写DownloadManager有很大的借鉴意义.在平时的开发中,当我们使用UIImageView加载一个网络上的图片时,其原理就是把图片下载下来,然后再赋 ...

  7. AFNetworking 3.0 源码解读(三)之 AFURLRequestSerialization

    这篇就讲到了跟请求相关的类了 关于AFNetworking 3.0 源码解读 的文章篇幅都会很长,因为不仅仅要把代码进行详细的的解释,还会大概讲解和代码相关的知识点. 上半篇: URI编码的知识 关于 ...

  8. Redis源码分析系列

    0.前言 Redis目前热门NoSQL内存数据库,代码量不是很大,本系列是本人阅读Redis源码时记录的笔记,由于时间仓促和水平有限,文中难免会有错误之处,欢迎读者指出,共同学习进步,本文使用的Red ...

  9. SDWebImage源码解读之SDWebImageDownloader

    SDWebImage源码解读之SDWebImageDownloader 第八篇 前言 SDWebImageDownloader这个类非常简单,作者的设计思路也很清晰,但是我想在这说点题外话. 如果有人 ...

  10. HttpClient 4.3连接池参数配置及源码解读

    目前所在公司使用HttpClient 4.3.3版本发送Rest请求,调用接口.最近出现了调用查询接口服务慢的生产问题,在排查整个调用链可能存在的问题时(从客户端发起Http请求->ESB-&g ...

随机推荐

  1. Java阻塞队列中的异类,SynchronousQueue底层实现原理剖析

    上篇文章谈到BlockingQueue的使用场景,并重点分析了ArrayBlockingQueue的实现原理,了解到ArrayBlockingQueue底层是基于数组实现的阻塞队列. 但是Blocki ...

  2. 重学c#系列——订阅发布与事件[二十六]

    前言 简单介绍一下订阅发布与事件. 正文 先来看一下委托的订阅与发布. public delegate void TestDelegate(); public class Cat { public T ...

  3. python实现图片转换pdf

    安装第三方库 linux平台 sudo apt install python3-reportlab python3-pil 示例代码 import sys from reportlab.pdfgen ...

  4. [opencv]一些重配遇到的问题(只针对我自己的电脑)

    1.我的opencv版本是4.5.3 2.环境变量这样配 3.对于每个项目,项目属性这样配: 其中包含目录: C:\Users\dxd\OPCV\opencv\build\include\opencv ...

  5. linux系统部署微服务项目

    **:如果使用阿里云linux服务器 1.设置容器镜像服务 在阿里云平台搜索 "容器镜像服务" 选择"CentOS" 安装/升级Docker客户端 配置镜像加速 ...

  6. pymysql.err.ProgrammingError: (1146, "Table 'autoplatform.webcasestepinfo' doesn't exist"

    在使用jmeter调试接口时,提示pymysql.err.ProgrammingError: (1146, "Table 'autoplatform.webcasestepinfo' doe ...

  7. JVM常用调优参数

    目录 JVM内存模型及常用参数 参数解释 垃圾收集器 Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC) Parallel Scavenge收集器(-XX: ...

  8. uniapp 微信小程序 根据经纬度解析地址(腾讯地图)

    //引入腾旭地图sdk import QQMapWX from '../../common/qqmap-wx-jssdk.js' onLoad(){ this.getMapAddress() }, m ...

  9. $_GET方法踩坑

    背景 写代码时,遇到一个奇怪的问题:小程序卡券解码接口老是报解码失败,苦寻了一个小时,发现原来是url参数经过thinkphp的I方法被过滤掉,而且涉及到PHP原生的$_GET 原因 I方法底层是原生 ...

  10. Python实验报告(第5章)

    实验5:字符串及正则表达式 一.实验目的和要求 学会使用字符串的常用操作方法和正确应用正则表达式 二.实验环境 软件版本:Python 3.10 64_bit 三.实验过程 1.实例01:使用字符串拼 ...