Redis入门（2）-- redis的持久化方式

---

前言

虽然redis的主要功能是用来进行缓存数据的，但是为了防止机器宕机后redis中数据的丢失，redis还是提供了持久化的操作

---

RDB

RDB (Redis DataBase) 将某一个时刻的内存快照，以二进制的方式写入磁盘

RDB的触发方式：

手动触发

• save 命令：使Redis处于阻塞状态，直到RDB持久化完成，才响应其他客户端发来的命令，这种操作是会影响用户程序响应时间的，所以不推荐
• bgsave 命令：fork出一个子进程执行持久化操作，主进程只在创建（fork）过程中有短暂的阻塞，子进程创建之后，主进程就可以响应客户端请求了，待持久化过程都结束了，再用这个临时文件替换上一次持久化好的文件。

redis如何确保fork子进程没有保存到某一时刻快照后的脏数据（就是在快照后的添加、修改的数据）：
redis是采用了一种写时拷贝的机制，在fork子进程读取某一时刻快照的过程中，父进程修改数据后会将内存中的数据拷贝出来，在拷贝出来的副本中进行修改，修改完后会将副本中的数据写回内存中

自动触发

• save m n：在m秒内，n个键值发生改变，则会自动触发持久化，通过bgsave执行，如果设置多个、只要满足其一就会触发，需要修改可以在 redis.conf文件中修改参数（下图是默认值）
• 

Fork

• Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
• 在linux程序中，fork()会产生一个和父进程相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，linux中引入了“写时复制技术”
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程内容复制一份给子进程

优缺点

优点

1. 适合大规模的数据恢复
2. 对数据完整性和一致性要求不高时更适合使用
3. 性能最大化，RDB在保存RDB文件时父进程唯一需要的就是fork出一个子进程，接下来的工作全部交由子线程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化Redis的性能

缺点

1. fork的时候，内存中的数据被克隆一份，大致2倍的膨胀需要考虑

2. 虽然redis在fork时使用写时拷贝技术，但是如果数据量庞大时还是比较消耗性能

3. 在备份周期一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照所有的修改

AOF（默认是不开启的）

AOF(Append Only File)以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件

开启AOF

在redis.conf中找到appendonly 将no改为yes就开启了，开启后会生成一个appendonly.aof 文件

AOF的同步策略

• always（每修改同步）：始终同步，每次发生的数据变化都会记录到日志，最多丢失一条，性能较差但是数据完整性比较好
• everysec（每秒同步）：异步完成，效率非常高，一旦系统出现宕机，那么一秒内修改的数据会丢失
• no（不同步）：不主动进行同步，由操作系统控制，可能丢失较多的数据

AOF的持久化流程

1. 客户端请求写命令被append追加到AOF缓冲区内
2. AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘的AOF文件中
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF进行数据的修复

找到redis-check-aof文件所在位置

redis-check-aof --fix appendonly.aof(需要恢复的文件名)

Rewrite压缩

AOF采用的是追加的方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

BGREWRITEAOF #AOF重写命令

AOF文件持续增长而过大时，会fork出一条新的进程来将文件重写（也就是先写临时文件最后再rename），redis4.0版本后的重写，实际上就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作

Redis会记录上次重写的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量的磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的因此设定redis要满足一定条件才进行重写

• auto-aof-rewrite-percentage:设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的两倍时触发）
• auto-aof-rewrite-min-size:设置重写的基准值，最小文件64MB。达到这个值开始重写
  

AOF文件重写条件

Redis记录此时的AOF文件大小（base_size）

AOF文件当前大小>=base_size+base_size*100%(默认) && 当前大小>=64MB(默认)的情况下

优缺点

优点

1. 备份机制更加稳健，丢失数据概率更低
2. 可读的日志文本，通过操作AOF稳健，可以处理误操作

缺点

1. 比起RDB占用更多的磁盘空间
2. 恢复备份速度要慢
3. 每次读写都同步的话，有一定的性能压力

两者如何选择

官方推荐：

1. 如果是做缓存最好两个都启用

2. 如果对数据不敏感，可以选单独用RDB

3. 不建议单独使用AOF，因为可能会出现bug

当两者同时启用时，会优先使用AOF文件，因为AOF相比于RDB更新频率高