作为一种定期清理无效数据的重要机制,主键失效存在于大多数缓存系统中,Reids也不例外。在Redis提供的诸多命令中,EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT以及SETEX和PSETEX均可以用来设置一条Key-Value对的失效时间,而一条Key-Value对一旦被关联了失效时间就会在到期后自动删除(或者说变得无法访问更为准确)。可以说,主键失效这个概念还是比较容易理解的,但是在具体实现到Redis中又是如何呢?最近本博主就对Redis中的主键失效机制产生了几个疑问,并根据这些疑问对其进行了仔细的探究,现总结所得如下,以飨各位看客。
一、除了调用PERSIST命令外,还有没有其他情况会撤销一个主键的失效时间?答案是肯定的。首先,在通过DEL命令删除一个主键时,失效时间自然会被撤销(这不是废话么,哈哈)。其次,在一个设置了失效时间的主键被更新覆盖时,该主键的失效时间也会被撤销(这貌似也是废话,哈哈)。但需要注意的是,这里所说的是主键被更新覆盖,而不是主键对应的Value被更新覆盖,因此SET、MSET或者是GETSET可能会导致主键被更新覆盖,而像INCR、DECR、LPUSH、HSET等都是更新主键对应的值,这类操作是不会触碰主键的失效时间的。此外,还有一个特殊的命令就是RENAME,当我们使用RENAME对一个主键进行重命名后,之前关联的失效时间会自动传递给新的主键,但是如果一个主键是被RENAME所覆盖的话(如主键hello可能会被命令RENAME world hello所覆盖),这时被覆盖主键的失效时间会被自动撤销,而新的主键则继续保持原来主键的特性。
二、Redis中的主键失效是如何实现的,即失效的主键是如何删除的?实际上,Redis删除失效主键的方法主要有两种:1)消极方法(passive way),在主键被访问时如果发现它已经失效,那么就删除它;2)积极方法(active way),周期性地从设置了失效时间的主键中选择一部分失效的主键删除。接下来我们就通过代码来探究一下这两种方法的具体实现,但在此之前,我们先看一看Redis是如何管理和维护主键的吧(注:本博文中的源码全部来自Redis-2.6.12)。
代码段一给出了Redis中关于数据库的结构体定义,这个结构体定义中除了id以外都是指向字典的指针,其中我们只看dict和expires,前者用来维护一个Redis数据库中包含的所有Key-Value对(其结构可以理解为dict[key]:value,即主键与值之间的映射),后者则用于维护一个Redis数据库中设置了失效时间的主键(其结构可以理解为expires[key]:timeout,即主键与失效时间的映射)。当我们使用SETEX和PSETEX命令向系统插入数据时,Redis首先将Key和Value添加到dict这个字典表中,然后将Key和失效时间添加到expires这个字典表中。当我们使用EXPIRE、EXPIREAT、PEXPIRE和PEXPIREAT命令设置一个主键的失效时间时,Redis首先到dict这个字典表中查找要设置的主键是否存在,如果存在就将这个主键和失效时间添加到expires这个字典表。简单地总结来说就是,设置了失效时间的主键和具体的失效时间全部都维护在expires这个字典表中。
代码段一:
typedef struct redisDb {
dict *dict;
dict *expires;
dict *blocking_keys;
dict *ready_keys;
dict *watched_keys;
int id;
} redisDb;
在大致了解了Redis是如何维护设置了失效时间的主键之后,我们就先来看一看Redis是如何实现消极地删除失效主键的。代码段二给出了一个名为expireIfNeeded的函数,这个函数在任何访问数据的函数中都会被调用,也就是说Redis在实现GET、MGET、HGET、LRANGE等所有涉及到读取数据的命令时都会调用它,它存在的意义就是在读取数据之前先检查一下它有没有失效,如果失效了就删除它。代码段二中给出了expireIfNeeded函数的所有相关描述,这里就不再重复它的实现方法了。这里需要说明的是在expireIfNeeded函数中调用的另外一个函数propagateExpire,这个函数用来在正式删除失效主键之前广播这个主键已经失效的信息,这个信息会传播到两个目的地:一个是发送到AOF文件,将删除失效主键的这一操作以DEL Key的标准命令格式记录下来;另一个就是发送到当前Redis服务器的所有Slave,同样将删除失效主键的这一操作以DEL Key的标准命令格式告知这些Slave删除各自的失效主键。从中我们可以知道,所有作为Slave来运行的Redis服务器并不需要通过消极方法来删除失效主键,它们只需要对Master唯命是从就OK了!
代码段二:
int expireIfNeeded(redisDb *db, robj *key) {
获取主键的失效时间
long long when = getExpire(db,key);
假如失效时间为负数,说明该主键未设置失效时间(失效时间默认为-1),直接返回0
if (when < 0) return 0;
假如Redis服务器正在从RDB文件中加载数据,暂时不进行失效主键的删除,直接返回0
if (server.loading) return 0;
假如当前的Redis服务器是作为Slave运行的,那么不进行失效主键的删除,因为Slave
上失效主键的删除是由Master来控制的,但是这里会将主键的失效时间与当前时间进行
一下对比,以告知调用者指定的主键是否已经失效了
if (server.masterhost != NULL) {
return mstime() > when;
}
如果以上条件都不满足,就将主键的失效时间与当前时间进行对比,如果发现指定的主键
还未失效就直接返回0
if (mstime() <= when) return 0;
如果发现主键确实已经失效了,那么首先更新关于失效主键的统计个数,然后将该主键失
效的信息进行广播,最后将该主键从数据库中删除
server.stat_expiredkeys++;
propagateExpire(db,key);
return dbDelete(db,key);
}
代码段三:
void propagateExpire(redisDb *db, robj *key) {
robj *argv[2];
shared.del是在Redis服务器启动之初就已经初始化好的一个常用Redis对象,即DEL命令
argv[0] = shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
检查Redis服务器是否开启了AOF,如果开启了就为失效主键记录一条DEL日志
if (server.aof_state != REDIS_AOF_OFF)
feedAppendOnlyFile(server.delCommand,db->id,argv,2);
检查Redis服务器是否拥有Slave,如果是就向所有Slave发送DEL失效主键的命令,这就是
上面expireIfNeeded函数中发现自己是Slave时无需主动删除失效主键的原因了,因为它
只需听从Master发送过来的命令就OK了
if (listLength(server.slaves))
replicationFeedSlaves(server.slaves,db->id,argv,2);
decrRefCount(argv[0]);
decrRefCount(argv[1]);
}
以上我们通过对expireIfNeeded函数的介绍了解了Redis是如何以一种消极的方式删除失效主键的,但是仅仅通过这种方式显然是不够的,因为如果某些失效的主键迟迟等不到再次访问的话,Redis就永远不会知道这些主键已经失效,也就永远也不会删除它们了,这无疑会导致内存空间的浪费。因此,Redis还准备了一招积极的删除方法,该方法利用Redis的时间事件来实现,即每隔一段时间就中断一下完成一些指定操作,其中就包括检查并删除失效主键。这里我们说的时间事件的回调函数就是serverCron,它在Redis服务器启动时创建,每秒的执行次数由宏定义REDIS_DEFAULT_HZ来指定,默认每秒钟执行10次。代码段四给出该时间事件创建时的程序代码,该代码在redis.c文件的initServer函数中。实际上,serverCron这个回调函数不仅要进行失效主键的检查与删除,还要进行统计信息的更新、客户端连接超时的控制、BGSAVE和AOF的触发等等,这里我们仅关注删除失效主键的实现,也就是函数activeExpireCycle。
代码段四:
if(aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL) == AE_ERR) {
redisPanic("create time event failed");
exit(1);
}
代码段五给出了函数activeExpireCycle的实现及其详细描述,其主要实现原理就是遍历处理Redis服务器中每个数据库的expires字典表中,从中尝试着随机抽样REDIS_EXPIRELOOKUPS_PER_CRON(默认值为10)个设置了失效时间的主键,检查它们是否已经失效并删除掉失效的主键,如果失效的主键个数占本次抽样个数的比例超过25%,Redis会认为当前数据库中的失效主键依然很多,所以它会继续进行下一轮的随机抽样和删除,直到刚才的比例低于25%才停止对当前数据库的处理,转向下一个数据库。这里我们需要注意的是,activeExpireCycle函数不会试图一次性处理Redis中的所有数据库,而是最多只处理REDIS_DBCRON_DBS_PER_CALL(默认值为16),此外activeExpireCycle函数还有处理时间上的限制,不是想执行多久就执行多久,凡此种种都只有一个目的,那就是避免失效主键删除占用过多的CPU资源。代码段五有对activeExpireCycle所有代码的详细描述,从中可以了解该函数的具体实现方法。
代码段五:
void activeExpireCycle(void) {
因为每次调用activeExpireCycle函数不会一次性检查所有Redis数据库,所以需要记录下
每次函数调用处理的最后一个Redis数据库的编号,这样下次调用activeExpireCycle函数
还可以从这个数据库开始继续处理,这就是current_db被声明为static的原因,而另外一
个变量timelimit_exit是为了记录上一次调用activeExpireCycle函数的执行时间是否达
到时间限制了,所以也需要声明为static
static unsigned int current_db = 0;
static int timelimit_exit = 0;
unsigned int j, iteration = 0;
每次调用activeExpireCycle函数处理的Redis数据库个数为REDIS_DBCRON_DBS_PER_CALL
unsigned int dbs_per_call = REDIS_DBCRON_DBS_PER_CALL;
long long start = ustime(), timelimit;
如果当前Redis服务器中的数据库个数小于REDIS_DBCRON_DBS_PER_CALL,则处理全部数据库,
如果上一次调用activeExpireCycle函数的执行时间达到了时间限制,说明失效主键较多,也
会选择处理全部数据库
if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;
执行activeExpireCycle函数的最长时间(以微秒计),其中REDIS_EXPIRELOOKUPS_TIME_PERC
是单位时间内能够分配给activeExpireCycle函数执行的CPU时间比例,默认值为25,server.hz
即为一秒内activeExpireCycle的调用次数,所以这个计算公式更明白的写法应该是这样的,即
(1000000 * (REDIS_EXPIRELOOKUPS_TIME_PERC / 100)) / server.hz
timelimit = 1000000*REDIS_EXPIRELOOKUPS_TIME_PERC/server.hz/100;
timelimit_exit = 0;
if (timelimit <= 0) timelimit = 1;
遍历处理每个Redis数据库中的失效数据
for (j = 0; j < dbs_per_call; j++) {
int expired;
redisDb *db = server.db+(current_db % server.dbnum);
此处立刻就将current_db加一,这样可以保证即使这次无法在时间限制内删除完所有当前
数据库中的失效主键,下一次调用activeExpireCycle一样会从下一个数据库开始处理,
从而保证每个数据库都有被处理的机会
current_db++;
开始处理当前数据库中的失效主键
do {
unsigned long num, slots;
long long now;
如果expires字典表大小为0,说明该数据库中没有设置失效时间的主键,直接检查下
一数据库
if ((num = dictSize(db->expires)) == 0) break;
slots = dictSlots(db->expires);
now = mstime();
如果expires字典表不为空,但是其填充率不足1%,那么随机选择主键进行检查的代价
会很高,所以这里直接检查下一数据库
if (num && slots > DICT_HT_INITIAL_SIZE &&
(num*100/slots < 1)) break;
expired = 0;
如果expires字典表中的entry个数不足以达到抽样个数,则选择全部key作为抽样样本
if (num > REDIS_EXPIRELOOKUPS_PER_CRON)
num = REDIS_EXPIRELOOKUPS_PER_CRON;
while (num--) {
dictEntry *de;
long long t;
随机获取一个设置了失效时间的主键,检查其是否已经失效
if ((de = dictGetRandomKey(db->expires)) == NULL) break;
t = dictGetSignedIntegerVal(de);
if (now > t) {
发现该主键确实已经失效,删除该主键
sds key = dictGetKey(de);
robj *keyobj = createStringObject(key,sdslen(key));
同样要在删除前广播该主键的失效信息
propagateExpire(db,keyobj);
dbDelete(db,keyobj);
decrRefCount(keyobj);
expired++;
server.stat_expiredkeys++;
}
}
每进行一次抽样删除后对iteration加一,每16次抽样删除后检查本次执行时间是否
已经达到时间限制,如果已达到时间限制,则记录本次执行达到时间限制并退出
iteration++;
if ((iteration & 0xf) == 0 &&
(ustime()-start) > timelimit)
{
timelimit_exit = 1;
return;
}
如果失效的主键数占抽样数的百分比大于25%,则继续抽样删除过程
} while (expired > REDIS_EXPIRELOOKUPS_PER_CRON/4);
}
}
三、Memcached删除失效主键的方法与Redis有何异同?首先,Memcached在删除失效主键时也是采用的消极方法,即Memcached内部也不会监视主键是否失效,而是在通过Get访问主键时才会检查其是否已经失效。其次,Memcached与Redis在主键失效机制上的最大不同是,Memcached不会像Redis那样真正地去删除失效的主键,而只是简单地将失效主键占用的空间回收。这样当有新的数据写入到系统中时,Memcached会优先使用那些失效主键的空间。如果失效主键的空间用光了,Memcached还可以通过LRU机制来回收那些长期得不到访问的空间,因此Memcached并不需要像Redis中那样的周期性删除操作,这也是由Memcached使用的内存管理机制决定的。同时,这里需要指出的是Redis在出现OOM时同样可以通过配置maxmemory-policy这个参数来决定是否采用LRU机制来回收内存空间(感谢@Jonathan_Dai同学在博文http://xenojoshua.com/2013/07/redis-lru/中对原文的指正)!
四、Redis的主键失效机制会不会影响系统性能?通过以上对Redis主键失效机制的介绍,我们知道虽然Redis会定期地检查设置了失效时间的主键并删除已经失效的主键,但是通过对每次处理数据库个数的限制、activeExpireCycle函数在一秒钟内执行次数的限制、分配给activeExpireCycle函数CPU时间的限制、继续删除主键的失效主键数百分比的限制,Redis已经大大降低了主键失效机制对系统整体性能的影响,但是如果在实际应用中出现大量主键在短时间内同时失效的情况还是会使得系统的响应能力降低,所以这种情况无疑应该避免。
相关推荐
通过本文的介绍,我们可以了解到Redis提供的多种缓存失效策略和主键失效机制是如何工作的。在实际开发中,根据不同的业务需求合理选择和配置这些策略,对于提升系统的性能和稳定性至关重要。希望本文能帮助读者更好...
可以说,主键失效这个概念还是比较容易理解的,但是在具体实现到 Redis 中又是如何呢?最近本博主就对 Redis 中的主键失效机制产生了几个疑问,并根据这些疑问对其进行了仔细的探究,现总结所得如下,以飨各位看客。
Redis 和 Memcached 作为两种流行的...总结起来,理解 Redis 和 Memcached 的失效机制对于优化缓存系统的性能和稳定性至关重要。在设计缓存策略时,要充分考虑时间同步、过期检查以及异常处理,以确保服务的正常运行。
6. **单服务消费与多服务消费**:消费组机制确保一条消息只被一个消费者消费,通过多个消费组实现多消费。 7. **顺序消费**:通过消息分区实现顺序消费,每个分区内的消息顺序保证。 8. **命令行操作**:如`kafka-...
消息队列的面试连环炮: 1. 为什么使用消息队列?...在实际面试中,这些知识点往往是考察应聘者对技术深度理解和问题解决能力的重要依据。通过上述内容的深入分析,可以有效提升应对Java面试,特别是大厂面试的能力。
通过对“爱旅行”项目的Token机制进行深入分析,我们可以看到Token作为一种有效的用户认证手段,在前后端分离的架构下具有重要的应用价值。通过对用户表的合理设计、Token数据结构的规划以及有效期的管理,可以有效...
- **基于ZooKeeper**:实现机制更为复杂,但提供了丰富的功能和高度的可靠性,适用于需要高度一致性和可靠性的场景。 综上所述,选择合适的分布式锁实现方案需要根据具体的应用场景、性能需求和可靠性要求来进行...
MySQL是世界上最流行的关系型数据库管理系统之一,经常在面试中被问到各种问题,尤其是在技术面试中。...在实际工作中,还需要了解事务处理、锁机制、性能调优、分区与分表、备份与恢复等更多主题。
2. 内存压力:大数据量可能导致缓存机制失效,增加内存负担。 3. 并发问题:高并发请求下,数据库锁竞争加剧,影响性能。 二、SQL调优策略 1. 索引优化:为经常用于查询的字段创建合适类型的索引,如主键索引、唯一...
MySQL 是一款广泛使用的开源关系型数据库管理...在面试中,深入理解这些概念和原理将有助于展示你的专业技能和解决问题的能力。此外,还需了解事务处理、锁机制、分区策略、性能优化、备份恢复等更多MySQL高级主题。
### 分布式架构知识点解析 #### 一、部署架构说明 **1.1 总体介绍** - **架构概述**:分布式系统的核心在于利用微服务技术,并...对于开发者而言,深入理解这些概念和技术细节对于构建高质量的分布式系统至关重要。
2. 非主键索引(二级索引):叶子节点存储主键值,InnoDB中,非主键索引需要通过主键值去查找实际数据。 **MyISAM与InnoDB的索引差异** MyISAM使用B+树,叶子节点存储数据物理地址,索引和数据文件分开;InnoDB的B...
Spring事务管理基于AOP实现,`@Transactional`失效可能因未开启事务、异常未被抛出等原因。 Spring容器启动流程包括加载配置、解析bean定义、实例化bean、依赖注入等。 Spring使用的设计模式包括工厂模式、代理...
### NoSQL分布式数据库知识点解析 #### 一、选择题知识点详解 ...这些知识点涵盖了 NoSQL 分布式数据库的重要概念和技术细节,对于理解和掌握 NoSQL 数据库的核心原理及其实现机制具有重要意义。
在Java中可以通过继承`Thread`类或实现`Runnable`接口的方式来创建线程。 **继承Thread类**: ```java class MyThread extends Thread { public void run() { System.out.println("Thread running"); } } ...
了解这些知识点有助于深入理解数据库的工作原理,优化查询性能,解决实际问题,对于数据库管理员和开发人员来说至关重要。在面试中,能够清晰地阐述这些概念和原理,将体现专业能力和问题解决能力。
MySQL 是一种广泛使用的开源关系型数据库管理系统,面试中经常涉及其特性和...了解这些核心概念,有助于在面试中展示你对MySQL的深入理解和应用能力。在实际工作中,合理地创建和使用索引,可以显著提升数据库的性能。