c# redis hashid如何设置过期时间_Redis系列（三）：Redis持久化机制（RDB & AOF）

在前两篇关于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系列之事务隔离