RDB

RDB（Redis Database）

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件，待持久化过程都结束了，再用这个临时文件替换上次持久化的文件。整个过程中，主进程不进行IO操作，这就确保了极高的性能。

如果需要大规模的数据恢复，且对于数据的完整度不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能会丢失（例如Redis突然宕机）

触发规则

  1. save的规则满足情况下，会自动触发rdb持久化
  2. 执行fulshall命令，会自动触发rdb持久化
  3. Redis shutdown时，也会生成一个rdb文件

如何恢复RDB文件

只需要将RDB文件放到reids启动目录下即可，redis会自动读取rdb文件。有时候生产环境我们还会对rdb文件进行备份。

优点

  1. 适合大规模的数据恢复
  2. 对数据的完整度要求不高

缺点

  1. 需要一定的时间间隔进行操作。如果Redis意外宕机了，最后一次持久化的数据就没有了
  2. fork进程的时候，会占用一定的内存空间

AOF

AOF （Append Only File）

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

如果AOF文件有错误，redis将启动失败。redis同事提供了一个aof修复工具redis-check-aof，使用命令redis-check-aof --fix appendonly.aof就可以修复错误（删除错误的一条命令）

doubly@xiaoyizideMacBook-Pro bin % redis-check-aof --fix appendonly.aof
0x              6a: Expected \r\n, got: 7364
AOF analyzed: size=128, ok_up_to=81, ok_up_to_line=26, diff=47
This will shrink the AOF from 128 bytes, with 47 bytes, to 81 bytes
Continue? [y/N]: y
Successfully truncated AOF

配置

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

重写规则

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

如果AOF文件大于64M，就会fork一个新的子进程将我们的文件来进行重写

优点

  1. 每一次修改都同步，文件的完整会更加好。
  2. 每秒同步一次，可能会丢失一秒的数据
  3. 从不同步，效率最高

缺点

  1. 相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢
  2. AOF运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化