Redis 源码解读之逐出策略
Redis 源码解读之逐出策略
背景和问题
本文想解决的问题:
- redis 触发逐出的时机是怎样的?
- redis 逐出策略有哪些?
- 如何在海量的 key 中快速找到逐出评价值(
idle
)最高的key,并将之逐出? - LFU 算法的频率是如何统计的?
结论
- redis 触发逐出的时机是怎样的?
如图,主要有两个地方会触发逐出。
- 更新 maxmemory 参数,导致实际使用内存大于该限制。
- 处理客户端请求,使用到的内存大于内存限制。
- 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.
- 如何在海量的 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;
- 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);
}
//... ...
}
}
扩展阅读
- lru-cache - redis.io
- Random notes on improving the Redis LRU algorithm - antirez.com
- Counting Large Numbers of Events in Small Registers - Robert Morris Bell Laboratories, Murray Hill, N.J.
Redis 源码解读之逐出策略的更多相关文章
- redis源码解读--内存分配zmalloc
目录 主要函数 void *zmalloc(size_t size) void *zcalloc(size_t size) void zrealloc(void ptr, size_t size) v ...
- (十)redis源码解读
一.redis工作机制 redis是 单线程,所有命令(set,get等)都会加入到队列中,然后一个个执行. 二.为什么redis速度快? 1.基于内存 2.redis协议resp 简单.可读.效率高 ...
- php-msf 源码解读【转】
php-msf: https://github.com/pinguo/php-msf 百度脑图 - php-msf 源码解读: http://naotu.baidu.com/file/cc7b5a49 ...
- 从koa-session源码解读session本质
前言 Session,又称为"会话控制",存储特定用户会话所需的属性及配置信息.存于服务器,在整个用户会话中一直存在. 然而: session 到底是什么? session 是存在 ...
- AFNetworking 3.0 源码解读 总结(干货)(下)
承接上一篇AFNetworking 3.0 源码解读 总结(干货)(上) 21.网络服务类型NSURLRequestNetworkServiceType 示例代码: typedef NS_ENUM(N ...
- AFNetworking 3.0 源码解读(八)之 AFImageDownloader
AFImageDownloader 这个类对写DownloadManager有很大的借鉴意义.在平时的开发中,当我们使用UIImageView加载一个网络上的图片时,其原理就是把图片下载下来,然后再赋 ...
- AFNetworking 3.0 源码解读(三)之 AFURLRequestSerialization
这篇就讲到了跟请求相关的类了 关于AFNetworking 3.0 源码解读 的文章篇幅都会很长,因为不仅仅要把代码进行详细的的解释,还会大概讲解和代码相关的知识点. 上半篇: URI编码的知识 关于 ...
- Redis源码分析系列
0.前言 Redis目前热门NoSQL内存数据库,代码量不是很大,本系列是本人阅读Redis源码时记录的笔记,由于时间仓促和水平有限,文中难免会有错误之处,欢迎读者指出,共同学习进步,本文使用的Red ...
- SDWebImage源码解读之SDWebImageDownloader
SDWebImage源码解读之SDWebImageDownloader 第八篇 前言 SDWebImageDownloader这个类非常简单,作者的设计思路也很清晰,但是我想在这说点题外话. 如果有人 ...
- HttpClient 4.3连接池参数配置及源码解读
目前所在公司使用HttpClient 4.3.3版本发送Rest请求,调用接口.最近出现了调用查询接口服务慢的生产问题,在排查整个调用链可能存在的问题时(从客户端发起Http请求->ESB-&g ...
随机推荐
- C温故补缺(八):结构体与共用体
结构体与共用体 结构体 是一个可以存储多个不同类型的变量的结构,类似于面对对象中的类(只有成员变量的类). struct tag { member-list member-list member-li ...
- kettle 链接oracle12c
jdbc连接cdb数据库时,url兼容以下2种模式: "jdbc:oracle:thin:@192.168.75.131:1521:oracle12c" "jdbc:or ...
- 如何通过 C#/VB.NET 将 PDF 转为 Word
众所周知,PDF 文档支持特长文件,集成度和安全可靠性都较高,可有效防止他人对 PDF 内容进行更改,所以在工作中深受大家喜爱.但是在工作中,我们不可避免的会对 PDF 文档进行修改或再编辑,这时我们 ...
- 【FAQ】申请Health Kit权限的常见问题及解答
华为运动健康服务(HUAWEI Health Kit)提供原子化数据开放,用户数据被授权获取后,应用可通过接口访问运动健康数据,对相关数据进行增.删.改.查等操作.这篇文章汇总了申请开通Health ...
- 基于U-Net网络的图像分割的MindStudio实践
摘要:本实践是基于Windows版MindStudio 5.0.RC3,远程连接ECS服务器使用,ECS是基于官方分享的CANN6.0.RC1_MindX_Vision3.0.RC3镜像创建的. 本文 ...
- WireShark抓包入门教学
wireshark抓包新手使用教程 Wireshark是非常流行的网络封包分析软件,可以截取各种网络数据包,并显示数据包详细信息.常用于开发测试过程各种问题定位.本文主要内容包括: 1.Wiresha ...
- WCF 服务容器化的一些问题
背景 目前项目当中存有 .NET Framework 和 .NET Core 两种类型的项目,但是都需要进行容器化将其分别部署在 Windows 集群和 Linux 集群当中.在 WCF 进行容器化的 ...
- tempdb日志文件暴增分析
背景 某医院信息科接到CIS系统磁盘空间不足告警,通过排查发现tempdb的日志文件暴增,已经涨到了130G左右,并且还在持续增长中.需要我们紧急排查原因. 现象 登陆到服务器里,确实看到了如上所说, ...
- Java中Elasticsearch 实现分页方式(三种方式)
目录 ES 简介 ES 的特点: 一.from + size 浅分页 二.scroll 深分页 scroll删除 三.search_after 深分页 ES 简介 Elasticsearch 是一个基 ...
- 每个Java程序员都必须知道的四种负载均衡算法
前言 一般来说,我们在设计系统的时候,为了系统的高扩展性,会尽可能的创建无状态的系统,这样我们就可以采用集群的方式部署,最终很方便的根据需要动态增减服务器数量.但是,要使系统具有更好的可扩展性,除了无 ...