搞懂Redis (五) - Redis持久化

Redis是内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题Redis供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失
快照(RDB文件)和追加式文件(AOF文件),下面介绍两种方式的原理

• RDB持久化方式会在一个特定的间隔保存那个时间点的数据快照.
• AOF持久化方式会记录每一个服务器收到的写操作.在服务启动时,这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。
• Redis的持久化是可以禁用的，就是可以让数据的生命周期只存在于服务器的运行时间里。
• 两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据。

1. RDB持久化
   RDB持久化产生的文件是一个经过压缩的二进制文件，这个文件可以被保存在硬盘中，可以通过这个文件还原数据库的状态，它可以手动执行，也可以在redis.conf中配置，定时执行。
   工作原理
   在进行RDB时，Redis的主进程不会做io操作，会fork一个子进程来完成操作：
   1、 Redis调用forks，同时拥有父进程和子进程
   2、 子进程将数据集写入到一个临时RDB文件中
   3、 当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。
   这种工作方式使得Redis可以从写时复制（copy-on-write）机制中获益（因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求）
   触发机制
   在Redis中RDB持久化的触发分成两种：手动触发和自动触发
   主动触发
   1、save命令是同步的命令，会占用主进程，会造成阻塞，阻塞所有客户端的请求
   2、bgsave是异步命令，进行持久化的时候，Redis还可以将继续响应客户端请求
   bgsave和save的对比

自动触发
1、 save自动触发配置，见下面配置，满足m秒内修改n次key，触发RDB

# 时间策略   save m n m秒内修改n次key，触发rdb
save 900 1
save 300 10
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

2、从节点全量复制时，主节点发送RDB文件给从节点完成复制时操作，主节点会触发bgsave命令
3、执行flushall命令，会触发RDB
4、退出Redis，且没有开启AOF时
优点：
1、RDB的内容为二进制的数据，占用内存更小，更紧凑，更适合作为备份文件
2、RDB对灾难恢复非常有用，它可以是一个紧凑的文件，可以更快的传输到远程服务器进行Redis服务恢复
3、RDB可以更大程度的提高Redis的运行速度，因为每次持久化时Redis都会fork一个子进行，进行数据持久化到磁盘，Redis主进程并不会执行磁盘I/O等操作
4、与AOF格式的文件相比，RDB文件可以更快的重启
缺点：
1、因为RDB只能保存某个时间间隔的数据，如果中途Redis服务被意外终止，则会丢失一段时间内的Redis数据
2、RDB需要经常fork才能使用子进程将其持久化在磁盘上。如果数据集很大，fork可能很耗时，并且如果数据集很大且CPU性能不佳，则可能导致Redis停止为客户端服务几毫秒甚至1s。

2. AOF(Append Only File)
   以日志的形式来记录每个写的操作，将Redis执行过的所有指令记录下来（读不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
   AOF配置项

# 默认不开启aof  而是使用rdb的方式
appendonly no

# 默认文件名
appendfilename "appendonly.aof"

# 每次修改都会sync 消耗性能
# appendfsync always
# 每秒执行一次 sync 可能会丢失这一秒的数据
appendfsync everysec
# 不执行 sync ,这时候操作系统自己同步数据，速度最快
# appendfsync no 

AOF的整个流程大体来看可分两步，一是命令的实时写入（如果是appendfsync everysec 配置，会有1s的损耗），二是对aof文件的重写

AOF重写机制
随着Redis的运行，AOF的日志会越来越长，如果实例宕机重启，那重放整个AOF将变得十分耗时，而在日志记录中，又有很多无意义的记录，比如我现在将一个数据incr一千次，那就不需要去记录这一千次的修改，只需记录最后的值即可。所以就需要进行AOF重写。
Redis提供了bgrewriteaof指令用于对AOF日志进行重写，该指令运行时会开辟一个子进程对内存进行遍历，然后将其转换为一系列的Redis的操作指令，再序列化到一个日志文件中。完成后再替换原有的AOF文件，至此完成。
同样也可以在redis.conf中对重写机制的触发配置：
通过将no-appendfsync-on-rewrite设置为yes，开启重写机制；
auto-aof-rewrite-percentage 100即比上次写入文件大小增长了100%再次触发重写。
auto-aof-rewrite-min-size 64mb意为当文件至少要达到64mb才会触发重写机制。
触发方式
1、 手动触发：bgrewriteaof
2、自动触发：根据配置规则来触发，当然触发的整体时间还是跟Redis的定时任务频率有关系
优点：
1、数据安全，AOF持久化可以配置appendfsync属性，有always，每进行一次命令操作就记录到aof文件中一次
2、通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题
3、AOF机制的rewrite模式。aof文件没被rewrite之前，（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）

缺点：
1、AOF文件比RDB文件大，且恢复速度慢。
2、数据集大的时候，比RDB启动效率低

3. RDB与AOF对比