【Redis】RDB & AOF 持久化

什么是持久化

Redis 是内存数据库，数据保存在内存中，当关机时，内存中的数据也就丢失了。

持久化就是把内存中的数据写入到磁盘上，保存内存在断电情况下，数据也不会丢失。

RDB （Redis DataBase）

• RDB 文件是在硬盘上的二进制文件；
• RDB 文件是 Redis 在内存存储的数据在某一时刻的快照；
• RDB 文件可在 Redis 启动的时候自动载入；
• RDB 文件是 Redis 节点复制时的媒介；

相关配置

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

# RDB持久化文件名
dbfilename dump.rdb

# 数据持久化文件存储目录
dir ./

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

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

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

持久化过程

Redis 会单独创建一个子线程来进行持久化操作，会先将内存中的数据写入到一个文件中，待持久化结束后，再替换掉上次持久化的文件，整个过程中，主进程不进行 IO 操作，保证了性能。

缺点：最后一次持久化的数据可能丢失（子进程还没有写入完成就被某种原因关闭）

触发 RDB 持久化机制的方式

手动触发 save 、bgsave

• save 命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。
• bgsave 命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started

自动触发规则，在配置文件配置

save 900 1
save 300 10
save 60 10000

AOF（Append Only File）

快照功能（RDB）并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。 从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

• 需要在配置文件开启，重启 Redis 服务生效。

  appendonly yes
  

相关配置

# 开启AOF持久化方式
appendonly yes

# AOF持久化文件名
appendfilename appendonly-<port>.aof

# appendfsync always # 每次修改值，都会同步数据到磁盘，消耗资源
appendfsync everysec #  每秒把缓冲区的数据同步到磁盘
# appendfsync no # 不执行数据同步，让操作系统在需要的时候刷新数据

# 数据持久化文件存储目录
dir ./

# 是否在执行重写时不同步数据到AOF文件
# 这里的 yes，就是执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite yes

# 触发AOF文件执行重写的最小尺寸
auto-aof-rewrite-min-size 64mb

# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100

执行流程

windows 下需要使用 redis-server.exe redis.windows.conf启动，配置文件才生效

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> set k5 v5
OK

可以看到修改值的操作都被记录下来了

AOF 文件修复

Redis 自带有 redis-check-aof 程序，用来修复 AOF 文件，修复后的文件能打开，但会出现数据丢失的情况，至少比 不能打开好。

删除 RDB 文件（里面有完整数据），破坏 AOF 文件（删除某些文件），模拟数据被破坏的场景。

启动 Redis 服务，启动失败

使用 aof 修复工具，修复成功

再次启动 Redis 服务，启动成功

查看所有的 Key，发现只有两个，其他的已经丢失，至少能打开了

扩展 对比

1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
   1. AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令恢复原始的数据，AOF命令以 Redis 协议追加保存每次写的操作到文件末尾。
   2. Redis还能对AOF文件进行后台重写（缩减某些格式），使得AOF文件的体积不至于过大。
2. 只做缓存，如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
3. 同时开启两种持久化方式
   1. 在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据,
      因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
   2. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，
      快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
4. 性能建议：
   1. 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
   2. 如果启用 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
   3. 如果不启用 AOF ，仅靠 Master-Slave Replication （主从复制） 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。