Redis——缓存的持久化

1、持久化机制

Redis的所有数据都保存在内存中，如果没有配置持久化功能，Redis重启后数据就会全部丢失，所以需要开启Redis的持久化功能，将数据保存到磁盘上，这样当Redis重启后，可以从磁盘中恢复数据。Redis提供两种方式进行持久化，一种是RDB持久化，另一种是AOF持久化。下面详细介绍这两种方式。

1.1、RDB持久化

RDB持久化是指在指定的时间间隔内定时地将内存中的数据写入磁盘，把内存中的数据保存到RDB文件中，是默认的持久化方式。Redis快照的过程是，首先Redis服务器使用fork函数复制一份当前进程（父进程）的副本（子进程）。然后，父进程继续接收并处理客户端发来的命令，而子进程将内存中的数据写入硬盘中的RDB临时文件。最后，当子进程写入完所有数据后会用RDB临时文件替换旧的RDB文件，如下图所示：

1.2、AOF持久化

追加（Append Only File，AOF）持久化方式会记录Redis客户端对服务器的每一次写操作命令，并将这些写操作追加保存到appendonly.aof文件（AOF文件）中。在Redis服务器重启时，会加载并运行AOF文件里的命令，以达到恢复数据的目的，如下图所示：

1.3、配置RDB

Redis的配置文件在Linux下是redis.conf文件，在Windows下是redis.windows.conf文件。本小节使用的实验环境是Linux，相应的配置文件是redis.conf文件，配置效果与Windows下的一致。

1.3.1、RDB文件路径和名称

RDB持久化是Redis默认的持久化方式，默认情况下Redis会把快照文件存储在当前目录下一个名为dump.rdb的文件内。

如果需要修改dump.rdb文件的存储路径和名称，可以通过修改配置文件redis.conf内的dbfilename参数和dir参数来实现：

# RDB文件名，默认为dump.rdb 
dbfilename dump.rdb 
 
# RDB文件和AOF文件存放的目录。默认为当前工作目录 
dir /usr/local/redis/bin

保存配置文件后，使用redis-server命令加载redis.conf配置文件并重新启动Redis服务器，然后使用CONFIG GET dir命令查看RDB文件的存储路径：

127.0.0.1:6379> CONFIG GET dir 
1) "dir" 
2) "/usr/local/redis/bin"

1.3.2、RDB的保存点

修改保存点选项，可以配置RDB的启用和禁用。可以通过修改配置文件redis.conf实现该功能。

（1）设置保存点，可以使Redis在每N秒内，如果数据发生了M次改变就保存快照文件。例如，下面这个保存点配置表示每60s内，如果数据发生了10000次以上的改变，Redis就会自动保存快照文件：

save 60 10000

保存点可以设置多个，设置保存点的格式如下：

save  

Redis可以设置多个保存点，例如Redis的配置文件redis.conf就默认设置了3个保存点：

save 900 1       # 900s后至少1个key有改变，就保存快照文件 
save 300 10      # 300s后至少10个key有改变，就保存快照文件 
save 60 10000    # 60s后至少10000个key有改变，就保存快照文件

（2）禁用快照保存。如果想禁用快照保存的功能，可以通过注释所有save配置，或者在最后一条save配置后添加如下的配置实现：

save ""

1.3.3、错误处理

后台存储发生错误时禁止写入，默认值为yes。默认情况下，如果Redis在后台生成快照文件时失败，就会停止接收数据，目的是让用户能知道数据没有持久化成功：

stop-writes-on-bgsave-error yes

1.3.4、数据压缩

启动RDB文件压缩，会耗费CPU资源，默认值为yes。如果想节省CPU资源，可以禁用压缩功能，但是数据集就会比没压缩的时候要大。

rdbcompression yes

1.3.5、数据校验

对RDB数据进行校验，会耗费CPU资源，默认值为yes。

rdbchecksum yes

1.3.6、手动生成快照文件

Redis提供了SAVE命令和BGSAVE命令用于手动生成快照文件。

（1）SAVE。SAVE命令会使用同步的方式生成RDB快照文件，将当前Redis实例的所有数据快照（Snap Shot）以RDB文件的形式保存到硬盘，默认情况下会把Redis数据持久化到dump.rdb文件中，并且在Redis服务器重启后自动读取dump.rdb文件。SAVE命令在Redis主线程中工作，会阻塞其他请求操作，在实际的生产环境中应该避免使用。

127.0.0.1:6379> SAVE 
OK

（2）BGSAVE。BGSAVE命令使用异步的方式保存当前Redis实例的所有数据快照到RDB文件，执行BGSAVE命令后，Redis会产生一个子进程并立刻恢复对客户端的服务。

127.0.0.1:6379> BGSAVE 
Background saving started 
(2.41s)

注意Redis配置文件里禁用了快照生成功能不影响SAVE命令和BGSAVE命令的效果。

1.4、配置AOF

1.4.1、启用AOF持久化

将redis.conf配置文件的配置项appendonly设置为yes，启用AOF持久化：

appendonly yes

修改redis.conf配置文件后，重启Redis服务器，Redis执行的每一条命令都会被记录到appendonly.aof文件中。但事实上，Redis并不会立即将命令写入硬盘文件中，而是将命令写入硬盘缓存。在接下来的可靠性配置中，可以配置从硬盘缓存写入硬盘的时间。

1.4.2、AOF文件路径和名称

通过修改配置文件redis.conf，修改dir、appendfilename对应的配置项来修改AOF文件路径和名称：

# 文件存放目录，与RDB文件共用。默认为当前工作目录 
dir /usr/local/redis 
 
# 默认文件名为appendonly.aof 
appendfilename "appendonly.aof"

1.4.3、可靠性

在redis.conf配置文件中可以通过appendfsync选项指定写入策略，有3个选项：

• always：每次收到Redis客户端的写命令就立即强制写入到AOF文件。这是最有保证的持久化方式，但也是速度最慢的，一般不推荐使用。
• everysec：每秒向AOF文件写入一次Redis客户端的写操作。在性能和持久化方面做了很好的折中，是推荐的方式。
• no：由操作系统来决定什么时候写入AOF文件，一般为30秒左右一次。这个方式性能最好，但是持久化方面没有保证，一般不推荐使用。

在redis.conf配置文件中配置appendfsync选项的实例如下：

# appendfsync always 
appendfsync everysec 
# appendfsync no

1.4.4、日志重写

随着写操作不断增加，AOF文件会越来越大，Redis可以在不中断服务的情况下在后台重建AOF文件。

日志重写的工作原理如下：

• Redis调用fork函数，产生一个子进程。
• 子进程把新的AOF文件写到一个临时文件里。
• 父进程持续把新的变动写到内存里的缓冲区（buffer），同时也会把这些新的变动写到旧的AOF文件里，这样即使重写失败也能保证数据的安全。
• 当子进程完成文件的重写后，父进程会获得一个信号，然后把内存里的缓冲区内容追加到子进程生成的新AOF文件里。

我们可以设置日志重写的条件。下面的实例表示当AOF文件的体积大于64 MB，并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）的时候，Redis将执行日志重写操作：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64MB

Redis会记住自从上一次重写后AOF文件的大小。要禁用自动的日志重写功能，可以把百分比设置为0：

auto-aof-rewrite-percentage 0

1.4.5、数据损坏修复

如果因为某些原因（例如服务器崩溃）AOF文件损坏了，导致Redis加载不了，可以通过以下方式进行修复：

• 备份AOF文件。
• 使用redis-check-aof命令修复原始的AOF文件：redis-check-aof --fix
• 在Linux下可以使用diff-u命令查看AOF文件和RDB文件的差异。
• 使用修复过的AOF文件重启Redis服务器。

1.4.6、从RDB切换到AOF

在Redis 2.2以后的版本中，从RDB切换到AOF，需要备份一个最新的dump.rdb文件，并把备份文件放在一个安全的地方。执行以下命令：

$ redis-cli config set appendonly yes 
$ redis-cli config set save ""

要确保数据与切换前一致，确保数据正确地写到AOF文件里。

1.4.7、备份

建议的备份方法如下：

• 创建一个定时任务，每小时和每天创建一个快照文件，并将快照文件保存在不同的文件夹里。
• 定时任务运行时，把太旧的文件删除。例如只保留48h内的按小时创建的快照文件和一到两个月的按天创建的快照文件。
• 每天确保一次把快照文件传输到数据中心外的地方进行保存，至少不能保存在Redis服务所在的服务器。

2、Redis过期key清除策略

Redis对过期key有3种清除策略：

• 被动清除：当读/写一个已经过期的key时，会触发惰性清除策略，直接清除这个过期key。
• 主动清除：由于惰性清除策略无法保证冷数据被及时清除，因此Redis会定期主动清除一批已过期的key。
• 当前已用内存超过maxmemory限定时，触发主动清除策略。

这里着重介绍第3种清除策略。在Redis中，允许用户设置最大使用内存大小为maxmemory（需要配合maxmemory-policy使用），设置为0表示不限制。当Redis内存数据集快到达maxmemory时，Redis会实行数据淘汰策略。Redis提供6种数据淘汰策略，如小表所示：

关于maxmemory设置，可以通过在redis.conf配置文件中的maxmemory参数设置，或者通过命令CONFIG SET动态修改。关于数据淘汰策略的设置，可以通过在redis.conf配置文件中的maxmemory-policy参数设置，或者通过命令CONFIG SET动态修改：

127.0.0.1:6379> CONFIG GET maxmemory 
1) "maxmemory" 
2) "0" 
127.0.0.1:6379> CONFIG SET maxmemory 100MB 
OK 
127.0.0.1:6379> CONFIG GET maxmemory 
1) "maxmemory" 
2) "104857600"