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持久化保存数据库状态的方法是将服务器执行的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文件）；信号处理函数执行完毕之后，父进程就可以继续像往常一样接受命令请求。

二、过期键删除策略

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

常见的几种删除策略：

• 定时删除：在设置键的过期时间的同时，创建一个定时器，键过期时立即执行对键的删除操作。
  优点：对内存是最友好的
  缺点：对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 -> 当内存使用超过配置的时候会返回错误，不会驱逐任何键