Redis提供了两种持久化功能,RDB持久化、AOF(Append Only File)持久化功能;内存淘汰机制,Redis服务器实际使用的是惰性删除和定期删除两种策略。

一、持久化机制

Redis是内存数据库,它将自己的数据库状态储存在内存里面,如果不想办法将储存在内存中的数据库状态保存到磁盘里面,那么一旦服务器进程退出,服务器中的数据库状态也会消失不见。为了解决这个问题,Redis提供了两种持久化功能,RDB持久化、AOF(Append Only File)持久化功能。

1.1 RDB持久化

命令: 使用SVAE 、BGSAVE命令可以生成RDB文件,将数据库状态存储到磁盘。

SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求:

redis> SAVE  // 等待直到RDB文件创建完毕
OK

BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程继续处理请求

redis> BGSAVE  // 派生子进程,并由子进程创建RDB文件
Background saving started

定期自动保存: 通过设置服务器配置的save选项,让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以设置多个保存条件,只要要其中任意一个条件被满足,服务器就会执行BGSAVE命令。

save 900 1		// 服务器在900秒之内,对数据库进行了至少1次修改
save 300 10		// 服务器在300秒之内,对数据库进行了至少10次修改
save 60 10000	// 服务器在60秒之内,对数据库进行了至少10000次修改

自动执行数据RDB持久化功能用到的字段定义,如下:

struct redisServer {
	// ...
	struct saveparam *saveparams;   /* Save points array for RDB */
	long long dirty;                /* Changes to DB from the last save */
	time_t lastsave;                /* Unix time of last successful save */
	// ...
}

Redis的服务器周期性操作函数serverCron默认每隔100毫秒就会执行一次,该函数用于对正在运行的服务器进行维护,它的其中一项工作就是检查save选项所设置的保存条件是否已经满足,如果满足的话,就执行BGSAVE命令。如下:

/* If there is not a background saving/rewrite in progress check if
* we have to save/rewrite now. */
for (j = 0; j < server.saveparamslen; j++) {
   struct saveparam *sp = server.saveparams+j;

   /* Save if we reached the given amount of changes,
    * the given amount of seconds, and if the latest bgsave was
    * successful or if, in case of an error, at least
    * CONFIG_BGSAVE_RETRY_DELAY seconds already elapsed. */
   if (server.dirty >= sp->changes &&
       server.unixtime-server.lastsave > sp->seconds)
   {
       serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...",
           sp->changes, (int)sp->seconds);
       rdbSaveBackground(server.rdb_filename,rsiptr);
       break;
   }
}

1.2 AOF持久化

aof持久化

原理: AOF持久化保存数据库状态的方法是将服务器执行的SET、SADD、RPUSH等命令保存到AOF文件中。被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的纯文本,比较易读。

AOF持久化功能的实现可以分为命令追加(append)、文件写入、文件同步(sync)三个步骤。
当AOF持久化功能处于打开状态时,服务器在执行完一个写命令之后,会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。是否进行文件写入、文件同步则通过一下参数控制:

# appendfsync always
appendfsync everysec
# appendfsync no
  • 当appendfsync的值为always时,每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件,并且同步AOF文件,效率最慢但是最安全的,即使故障停机也只会丢失一个事件循环中所产生的命令数据;

  • 当appendfsync的值为everysec时,每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件,并且每隔一秒对AOF文件进行一次同步。从效率上来讲,everysec模式足够快,故障停机会只丢失一秒的命令数据。

  • 当appendfsync的值为no时,每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件,何时对AOF文件进行同步,则由操作系统控制。该模式下速度是最快的,这种模式会在系统缓存中积累一段时间的写入数据,单次同步时长通常是三种模式中时间最长的。从平摊操作的角度来看,no模式和everysec模式的效率类似,故障停机时将丢失上次同步AOF文件之后的所有写命令数据。

AOF重写

AOF持久化是通过保存被执行的写命令来记录数据库状态的,所以随着服务器运行时间的流逝,AOF文件会越来越大,如果不加以控制的话,体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响,并且AOF文件的体积越大,使用AOF文件来进行数据还原所需的时间就越多。

为了解决AOF文件体积膨胀的问题,Redis提供了AOF文件重写(rewrite)功能。通过该功能,Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件,新旧两个AOF文件所保存的数据库状态相同,但新AOF文件不会包含任何浪费空间的冗余命令,所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

AOF文件重写的实现

  • AOF文件重写在子进程中进行处理,不对现有的AOF文件进行任何操作,通过读取服务器当前的数据库状态来实现。
  • 子进程在进行AOF重写期间,服务器继续处理命令请求,造成数据状态不一致,所以引入了重写缓冲区解决此问题;Redis服务器执行完一个写命令之后,它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。
    aof重写
  • 子进程完成AOF重写之后,会向父进程发送一个信号,父进程在接到该信号会调用一个信号处理函数(将AOF重写缓冲区中的所有内容写入到新AOF文件,对新的AOF文件进行改名,原子地覆盖现有的AOF文件);信号处理函数执行完毕之后,父进程就可以继续像往常一样接受命令请求。

二、过期键删除策略

在设置数据库过期键的时候会指定过期时间,那么一个键过期了,何时进行删除呢?

常见的几种删除策略:

  • 定时删除:在设置键的过期时间的同时,创建一个定时器,键过期时立即执行对键的删除操作。
    优点:对内存是最友好的
    缺点:对CPU时间是最不友好的

  • 定期删除:每隔一段时间,程序就对数据库进行一次检查,删除里面的过期键。
    优点:对内存和CPU的影响可调节
    缺点:如何确定删除操作的频率和时长

  • 惰性删除:键过期后不执行删除操作,每次从键空间中获取键时,检查键是否过期,如过期则删除该键;如果没有过期则返回该键。
    优点:对内存是最不友好的
    缺点:对CPU时间是最友好的、不被访问的过期键永远无法删除造成内存泄漏

Redis采用的过期删除策略

Redis服务器实际使用的是惰性删除和定期删除两种策略:通过配合使用这两种删除策略,服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。

惰性删除策略的实现

在执行get set等命令时会先调用函数expireIfNeeded对过期键进行处理

  1. 获取键的过期时间 when
  2. 如果是从库直接返回 now > when
  3. 是主库,未到过期时间不做任何操作直接返回
  4. 是主库,已过期,写AOF文件-->通知从库删除过期键-->删除过期键

定期删除策略的实现

activeExpireCycle

  1. 循环所有数据库进行过期操作;
  2. 如果库中没有设置了过期时间的key,则跳过该库;
  3. 如果只有不到1%的slots中有过期键,停止处理,等待更好的时间进行过期删除操作;
  4. 从当前库中设置了过期时间的key中随机取指定个数(默认20)的key判断是否过期,过期则删除;
  5. 判断当前库随机取的key中,已经过期的key占比超过25%则继续循环该库进行删除操作;
  6. 当函数运行超过了指定的时间,为防止长时间占用CPU停止所有操作,记录当前循环到哪一个库(变量 current_db),下次循环从此库开始执行。

内存淘汰策略

volatile-lru -> 加入键的时候如果过限,首先从设置了过期时间的键集合中驱逐最久没有使用的键
allkeys-lru -> 加入键的时候,如果过限,首先通过LRU算法驱逐最久没有使用的键
volatile-lfu -> 从所有配置了过期时间的键中驱逐使用频率最少的键
allkeys-lfu -> 从所有键中驱逐使用频率最少的键
volatile-random -> 加入键的时候如果过限,从过期键的集合中随机驱逐
allkeys-random -> 加入键的时候如果过限,从所有key随机删除
volatile-ttl -> 从配置了过期时间的键中驱逐马上就要过期的键
noeviction -> 当内存使用超过配置的时候会返回错误,不会驱逐任何键