在前两篇关于Redis的文章中，已经详细的介绍了Redis常用的数据结构相关内容，如果还没看的小伙伴可以先过一遍【Redis基本数据类型，Redis跳跃表详解】。本篇文章主要介绍：Redis数据持久化机制（RDB & AOF）。在此之前需要先了解一下Redis服务器的数据库以及Redis对过期键的处理策略是怎样的，有助于理解持久化机制内容。

Redis服务器中的数据库

对于我们都很熟悉的数据库MySQL，我们知道在MySQL中可以创建多个库。同样地，Redis服务器中也是有数据库这一概念的。如果不指定具体的数量，默认会有16个数据库，并且数据库与数据库之间的数据是隔离的。

• Redis数据库的原理

Redis服务器是通过redisServer结构体表示的，其中redisDb一个是用来保存所有的数据库的数组，dbnum表示数据库的数量（默认16，可以修改配置），Redis中对于每个数据库是通过redisDb结构体表示的。redisServer和redisDb的源码如下：

struct redisServer{  
    //  redisDb数组,表示服务器中所有的数据库
    redisDb *db;  
    //  服务器中数据库的数量
    int dbnum;  
}; 

typedef struct redisDb { 
    //  数据库ID标识
    int id;
    //  键空间，存放着所有的键值对
    dict *dict; 
    //  过期哈希表，保存着键的过期时间  
    dict *expires;  
    //  被watch命令监控的key和相应client 
    dict *watched_keys;   
    //  数据库内所有键的平均TTL（生存时间）
    long long avg_ttl;       
} redisDb;

从源码中可以知道，最重要的属性是dict *dict，它是用来存放所有的键值对。对于dict数据结构（哈希表）可以参考上篇文章Redis基本数据类型，这里不再赘述。我们将存储所有键值对的dict称为键空间。其示意图参考如下：

另外，我们知道Redis是C/S架构的，Redis客户端是通过redisClient结构体表示的，源码如下：

typedef struct redisClient{  
    //  客户端当前所选数据库
    redisDb *db;  
}redisClient;

【小结】：Redis的数据库是使用字典（哈希表）作为底层存储实现的，对数据库的增删改查都是构建在字典的操作之上的。

基于上述键值对存储结构示意图，执行Redis命令如：GET message -- "Hello Redis"。

Redis键过期处理策略

• 键的过期时间

Redis是基于内存的，内存是非常昂贵的资源，并且容量是比较小的。所以我们需要处理掉不常使用的数据，保留常用数据。Redis提供了键的过期时间（生存时间）设置。

1. 设置键的生存时间可以通过EXPIRE或者PEXPIRE命令；
2. 设置键的过期时间可以通过EXPIREAT或者PEXPIREAT命令；

其中EXPIRE、PEXPIRE、EXPIREAT都是通过PEXPIREAT命令实现的。

• 键过期策略

通过设置过期时间，过期键到时间会立即删除吗？回答这个问题，需要了解一下删除策略：

1. 定时删除：到时间点就把所有过期的键删除（对内存是友好的，对CPU不友好）；
2. 惰性删除：每次从键空间取键的时候，判断键是否过期，如果是就删除（对内存不友好，对CPU友好）；
3. 定期删除：每隔一段时间删除过期键，限制删除的执行时长和频率（内存和CPU的折中）；

【注】：Redis采用惰性删除&定期删除两种策略，所以在Redis中如果过期键到了过期时间了未必被立即删除。

• 内存淘汰机制

基于上述删除策略，如果遗漏了很多过期的键，也没有办法及时去查（惰性删除），大量过期的键堆积在内存中，导致Redis内存几乎耗尽，这种情况如何处理呢？

当然，我们可以设置内存最大使用量，当内存使用量超出时，会执行数据淘汰策略。

Redis的内存淘汰策略机制有以下几种：

一般使用场景：使用Redis缓存数据时，为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用allkeys-lru淘汰策略，将最近最少使用的数据淘汰。

Redis持久化机制

Redis的数据全部存储在内存中，如果异常突然宕机，数据就会全部丢失，因此必须有一套机制来保证Redis数据不会因为故障的发生而丢失，这种机制就是Redis持久化机制，它会将内存中的数据状态保存到磁盘中。

介绍Redis持久化机制之前，先看一下从客户端发起请求开始，到服务器真实写入磁盘，这期间发生哪些操作，以一张示意图表示：

对上图进行简单描述：

1. Client向数据库发送写命令（数据在Client内存中）；
2. 数据库接收到Client的写请求（数据在Server内存中）；
3. 数据库调用系统API将数据写入磁盘（数据在内核缓冲区中）；
4. 操作系统将写缓冲区传输到磁盘控制器（数据在磁盘缓存中）；
5. 磁盘控制器将数据写入实际的物理介质中（数据在磁盘中）。

Redis提供了两种不同的持久化机制来将数据存储到磁盘中：

（1） RDB（基于快照）：将某一时刻的所有数据保存到一个RDB文件中

（2） AOF（Append-Only-File）：当Redis服务器执行写命令时，将执行的写命令保存到AOF文件中

• RDB持久化机制（快照持久化）

RDB触发机制分为手动触发和自动触发两种。RDB持久化所生成的RDB文件是一个经过压缩处理的二进制文件，Redis可以通过这个文件还原数据库的数据。

1. 手动触发
1. SAVE：会阻塞Redis服务器进程，服务器不能接收任何请求，直到RDB文件创建完毕
2. BGSAVE：Redis进程执行fork()操作创建出一个子进程，在后台完成RDB持久化过程

2. 自动触发

    save 900 1              #  在900秒(15分钟)之后，至少有1个key发生变化
    save 300 10            #  在300秒(5分钟)之后，至少有10个key发生变化
    save 60 10000        #  在60秒(1分钟)之后，至少有10000个key发生变化

Redis持久化流程（BGSAVE执行流程）：

【总结】：通过手动调用SAVE或者BGSAVE命令或者配置条件触发，将数据库某一时刻的数据快照，生成RDB文件实现持久化。

• AOF持久化机制（文件追加）

AOF是通过保存Redis服务器所执行的写命令来记录数据库的数据的。以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。

AOF的使用：在redis.conf配置文件中，将appendonly设置为yes，默认是no。

1. AOF持久化机制实现

AOF持久化机制实现分三个步骤：

Step1：命令追加：命令写入aof_buf缓冲区

Step2：文件写入：调用flushAppendOnlyFile函数，考虑是否要将aof_buf缓冲区写入AOF文件中

Step3：文件同步：考虑是否将内存缓冲区数据真正写入到磁盘

其中，flushAppendOnlyFile函数的行为是由服务器的appendfsyn配置项决定的：

    appendfsync always     # 每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec   # 每秒钟同步一次，该策略为AOF的默认策。
    appendfsync no         # 从不同步。高效但是数据不会被持久化

有一个问题需要在这里进行简单的说明：写命令为什么先写入缓冲区？

由于Redis是单线程响应命令，所以每次写AOF文件都直接追加到硬盘中，那么写入的性能完全取决于硬盘的负载，所以Redis会将命令写入到缓冲区中，然后执行文件同步操作，再将缓冲区内容同步到磁盘中，这样就很好的保持了高性能。

2. AOF重写

Redis在长期运行的过程中，AOF日志会越变越长。如果实例宕机重启，重放整个AOF日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对AOF日志 “瘦身”。

Redis提供了bgrewriteaof指令用于对AOF日志进行瘦身。其 原理 就是 开辟一个子进程 对内存进行 遍历 转换成一系列Redis的操作指令，序列化到一个新的AOF日志文件 中。序列化完毕后再将操作期间发生的 增量AOF日志 追加到这个新的AOF日志文件中，追加完毕后就立即替代旧的AOF日志文件了，瘦身工作就完成了。

【说明】：AOF重写不需要对现有的AOF文件进行任何的读取、分析。AOF重写是通过读取服务器当前数据库的数据来实现的！

Redis将AOF重写程序放到子进程里执行(bgrewriteaof命令)，像BGSAVE命令一样fork出一个子进程来完成重写AOF的操作，从而不会影响到主进程。AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致！

☆ 为了解决数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，这个缓存区会在服务器创建出子进程之后使用。

• RDB & AOF比较
• RDB的优点：载入时恢复数据快，文件体积小
• RDB的缺点：会一定程度上丢失数据（因为系统如果在定时持久化之前出现宕机，此时还没来得及写入磁盘的数据都将会丢失）
• AOF的优点：丢失数据少（默认配置只丢失一秒的数据）
• AOF的缺点：恢复数据相对较慢，文件体积大

【说明】：如果Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)

往期精彩文章

Redis系列（二）：跳跃表详解

Redis系列（一）：与Redis的第一次相识

MySQL系列之精华篇

MySQL系列之MVCC多版本并发控制

MySQL系列之数据库锁

MySQL系列之数据库索引

MySQL系列之事务隔离