redis (四) RDB&AOF日志

​ Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快很多。但是一旦进程退出，Redis 的数据就会丢失。

​ 为了解决这个问题，Redis 提供了 RDB 和 AOF 两种持久化方案，将内存中的数据保存到磁盘中，避免数据丢失。

RDB

​ 把当前 Redis 进程的数据生成时间点快照( point-in-time snapshot ) 保存到存储设备的过程,为redis默认持久化方式.

持久化简单过程

1. 调用bgsave命令,父进程接收命令判断是否可持续化,如果当前存在正在执行的rdb或aof持久化,则直接返回.
2. 调用fork命令,创建一个子进程来执行持久化逻辑.
3. 主进程继续响应客户端命令.
4. 子进程将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的rdb文件。
5. 通知父进程持久化结束,重置状态.

触发方式

• save规则 : serverCron中save m n配置规则自动触发；

• 主从复制 : 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会出发bgsave；

• 未开启AOF执行shutdown命令时: 自动执行bgsave

• debug reload命令: save当前的rdb文件，并清空当前数据库，重新加载rdb,加载与启动时加载类似，加载过程中只能服务部分只读请求.

• save命令: 阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令,直到RDB过程完成为止。

• bgsave命令 : Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求.

涉及配置

• save: 配置触发 redis的 rdb 持久化条件. save “” 可停用持久化.

save 20 3 表示在20秒内如果至少有3个key发生变化，则保存

• stop-writes-on-bgsave-error: 默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。

• rdbcompression : 默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

• rdbchecksum : 默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗.

• dbfilename : 设置快照的文件名，默认是 dump.rdb

• dir : 设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

rdb优点和缺点

优点

• RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
• 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快.

缺点

• 影响性能: RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法, 频繁执行成本过高.
• 版本不兼容: RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题.
• 数据存在丢失: 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改.

数据恢复

备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

AOF

​ 以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据.

持久化简单过程

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

涉及配置

• appendonly : 默认no, 开启aof持久化的开关.

• appendfilename : 设置快照的文件名，默认是”appendonly.aof”

• appendfsync : 同步频率设置

  appendfsync always # 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
  appendfsync everysec # 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  appendfsync no # redis不主动进行同步，把同步时机交给操作系统.
  

AOF优点和缺点

优点

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

缺点

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 若每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。