Redis持久化机制

持久化机制

通常来说，应该同时使用两种持久化方案，以保证数据安全：

• 如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化

• 如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可

• 如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启

• 如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整

RDB模式(内存快照)#

RDB（Redis Database Backup File，Redis数据备份文件）持久化方式：是指用数据集快照的方式半持久化模式记录 Redis 数据库的所有键值对，在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点

• RDB快照是一个压缩过的非常紧凑的文件。保存着某个时间点的数据集，适合做数据的备份，灾难恢复

• 可最大化Redis的的性能。在保存RDB文件，服务器进程只需要fork一个子进程来完成RDB文件创建，父进程不需要做IO操作

• 与AOF相比，恢复大数据集的时候会更快

缺点

• RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据

• Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时

① 创建

当 Redis 持久化时，程序会将当前内存中的数据库状态保存到磁盘中。创建 RDB 文件主要有两个 Redis 命令：SAVE 和 BGSAVE。

② 载入

服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

save同步保存#

save 命令是同步操作，执行命令时，会 阻塞 Redis 服务器进程，拒绝客户端发送的命令请求。

具体流程如下：

由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。因此很少在生产环境直接使用SAVE 命令，可以使用BGSAVE 命令代替。如果在BGSAVE命令的保存数据的子进程发生错误的时，用 SAVE命令保存最新的数据是最后的手段。

bgsave异步保存#

bgsave 命令是异步操作，执行命令时，子进程执行保存工作，服务器还可以继续让主线程处理客户端发送的命令请求。

具体流程如下：

Redis使用Linux系统的fock()生成一个子进程来将DB数据保存到磁盘，主进程继续提供服务以供客户端调用。如果操作成功，可以通过客户端命令LASTSAVE来检查操作结果。

自动保存#

可通过配置文件对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动进行数据集保存操作:

Copy
# RDB自动持久化规则
# 当 900 秒内有至少有 1 个键被改动时，自动进行数据集保存操作
save 900 1
# 当 300 秒内有至少有 10 个键被改动时，自动进行数据集保存操作
save 300 10
# 当 60 秒内有至少有 10000 个键被改动时，自动进行数据集保存操作
save 60 10000

# RDB持久化文件名
dbfilename dump-<port>.rdb

# 数据持久化文件存储目录
dir /var/lib/redis

# bgsave发生错误时是否停止写入，通常为yes
stop-writes-on-bgsave-error yes

# rdb文件是否使用压缩格式
rdbcompression yes

# 是否对rdb文件进行校验和检验，通常为yes
rdbchecksum yes

默认配置#

RDB 文件默认的配置如下：

Copy
################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
# 在给定的秒数和给定的对数据库的写操作数下，自动持久化操作。
#  save <seconds> <changes>
# 
save 900 1
save 300 10
save 60 10000
#bgsave发生错误时是否停止写入，一般为yes
stop-writes-on-bgsave-error yes
#持久化时是否使用LZF压缩字符串对象?
rdbcompression yes
#是否对rdb文件进行校验和检验，通常为yes
rdbchecksum yes
# RDB持久化文件名
dbfilename dump.rdb
#持久化文件存储目录
dir ./

AOF模式(日志追加)#

AOF（Append Only File，追加日志文件）持久化方式：是指所有的命令行记录以 Redis 命令请求协议的格式完全持久化存储保存为 aof 文件。Redis 是先执行命令，把数据写入内存，然后才记录日志。因为该模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog，AOF更适合做热备。

优点

• 数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）
• AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复

缺点

• 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB。 不过在一般情况下，每秒fsync的性能依然非常高

持久化流程#

① 命令追加

若 AOF 持久化功能处于打开状态，服务器在执行完一个命令后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。

② 文件同步

服务器每次结束一个事件循环之前，都会调用 flushAppendOnlyFile 函数，这个函数会考虑是否需要将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件里。flushAppendOnlyFile 函数执行以下流程：

• WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件；
• SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。

这个函数是由服务器配置的 appendfsync 的三个值：always、everysec、no 来影响的，也被称为三种策略：

• always：每条命令都会 fsync 到硬盘中，这样 redis 的写入数据就不会丢失。

• everysec：每秒都会刷新缓冲区到硬盘中(默认值)。

  

• no：根据当前操作系统的规则决定什么时候刷新到硬盘中，不需要我们来考虑。

数据加载

• 创建一个不带网络连接的伪客户端

• 从 AOF 文件中分析并读取出一条写命令

• 使用伪客户端执行被读出的写命令

• 一直执行步骤 2 和 3，直到 AOF 文件中的所有写命令都被处理完毕为止

文件重写#

为何需要文件重写

• 为了解决 AOF 文件体积膨胀的问题

• 通过重写创建一个新的 AOF 文件来替代现有的 AOF 文件，新的 AOF 文件不会包含任何浪费空间的冗余命令

文件重写的实现原理

• 不需要对现有的 AOF 文件进行任何操作

• 从数据库中直接读取键现在的值

• 用一条命令记录键值对，从而代替之前记录这个键值对的多条命令

后台重写

为不阻塞父进程，Redis将AOF重写程序放到子进程里执行。在子进程执行AOF重写期间，服务器进程需要执行三个流程：

• 执行客户端发来的命令

• 将执行后的写命令追加到 AOF 缓冲区

• 将执行后的写命令追加到 AOF 重写缓冲区

默认配置#

AOF 文件默认的配置如下：

Copy
############################## APPEND ONLY MODE ###############################
#开启AOF持久化方式
appendonly no
#AOF持久化文件名
appendfilename "appendonly.aof"
#每秒把缓冲区的数据fsync到磁盘
appendfsync everysec
# appendfsync no
#是否在执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite no
# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100
#触发AOF文件执行重写的最小size
auto-aof-rewrite-min-size 64mb
#redis在恢复时，会忽略最后一条可能存在问题的指令
aof-load-truncated yes
#是否打开混合开关
aof-use-rdb-preamble yes

AOF文件格式说明#

Copy
# CRLE为为换行，结尾均以回车符\r和换行符\n结尾
*3CRLE       # *3表示有3个参数，命令本身也是参数的一部分，而且总是第一个参数
$3CRLE       # 第一个参数的字节数，对应于SET命令字长度
SETCRLE      # 第一个参数，总是为命令本身
$5CRLE       # 第二个参数长度，5表示第二个参数长度为5字节
mykeyCRLE    # 第二个参数值
$7CRLE       # 第三个参数长度为7字节
myvalueCRLE  # 第三个参数值

过期策略#

过期策略用于处理过期缓存数据。Redis采用过期策略：惰性删除 + 定期删除。memcached采用过期策略：惰性删除。

定时过期#

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期#

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

定期过期#

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。expires字典会保存所有设置了过期时间的key的过期时间数据，其中 key 是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

淘汰策略#

Redis淘汰机制的存在是为了更好的使用内存，用一定的缓存丢失来换取内存的使用效率。当Redis内存快耗尽时，Redis会启动内存淘汰机制，将部分key清掉以腾出内存。当达到内存使用上限超过maxmemory时，可在配置文件redis.conf中指定 maxmemory-policy 的清理缓存方式。

Copy
# 配置最大内存限制
maxmemory 1000mb
# 配置淘汰策略
maxmemory-policy volatile-lru

LRU(最近最少使用)#

• volatile-lru：从已设置过期时间的key中，挑选最近最少使用(最长时间没有使用)的key进行淘汰
• allkeys-lru：从所有key中，挑选最近最少使用的数据淘汰

LFU(最近最不经常使用)#

• volatile-lfu：从已设置过期时间的key中，挑选最近最不经常使用(使用次数最少)的key进行淘汰
• allkeys-lfu：从所有key中，选择某段时间内内最近最不经常使用的数据淘汰

Random(随机淘汰)#

• volatile-random：从已设置过期时间的key中，任意选择数据淘汰
• allkeys-random：从所有key中，任意选择数据淘汰

TTL(过期时间)#

• volatile-ttl：从已设置过期时间的key中，挑选将要过期的数据淘汰
• allkeys-random：从所有key中，任意选择数据淘汰

No-Enviction(驱逐)#

• noenviction（驱逐）：当达到最大内存时直接返回错误，不覆盖或逐出任何数据