Redis持久化方式：RDB和AOF

RocketMQ思维导图，不看会后悔哟
Mysql思维导图分享

上面思维导图可去gongzhonghao回复：扣扣号，获取联系方式后找我免费获得可编辑版本。 后面会继续分享其他思维导图，包括Redis、JVM、并发编程、RocketMQ、RabbtiMQ、Kafka、spring、Zookeeper、Dubbo等等

---

原文链接戳这里

RDB（Redis Database)

原理

  RDB就是将某一时刻的内存数据快照 以二进制形式写到磁盘里。

  由于RDB⽂件是保存在硬盘上的，所以即使Redis崩溃或者退出，只要RDB⽂件存在，就可以⽤它来恢复还原数据库的状态。它利用了系统的COW(copy on write)机制。

触发条件

  触发RDB的持久化有两种方式：手动触发和自动触发

  1. 手动触发

• 调用save命令：会阻塞当前Redis服务器直到RDB文件创建完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境非必要不要使用。

• 调用bgsave命令：通过执行fork操作创建一个子进程来进行持久化 ，减少了父进程的阻塞。但是在fork阶段也会阻塞父进程（时间很短）。

  2. 自动触发

• 在redis.conf中配置“save m n”。表示当m秒内数据有n次变化时就会自动触发bgsave

• 从节点执行全量复制操作时，主节点自动执行bgsave生成RDB文件并发送给从节点

• 执行debug reload命令重新加载Redis时，也会自动触发save操作

• 执行shutdown命令时，如果没有开启AOF则自动执行bgsave

优缺点

 RDB的优点是体积小，恢复数据快。缺点是生成二进文件更耗性能，且是间隔保存，丢失数据风险更大

AOF（Append-only File)

原理

 AOF以独立日志的方式记录每条写和修改命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的。

 AOF可设置为总是保存，但是一般都是设置1秒保存一次。我们生产时就是这样设置的，运维给出的建议是，不要希望redis作数据的一致性保证，它只为了解决高并发的问题的，一致性通过好的架构设计去保证。

工作流程

• 命令追加到aof_buf（缓冲区）中。

• aof_buf（缓冲区）根据设置的刷盘策略向磁盘同步。

• 文件变大后对AOF文件进行重写，以减少文件体积。

• redis服务器重启时，加载AOF文件进行数据恢复。

刷盘策略

• appendfsync always：每次写入都进行刷盘操作，对性能影响最大，占用磁盘 IO 较高，数据安全性最高

• appendfsync everysec：1秒刷一次盘，对性能影响相对较小

• appendfsync no：写入aof_buf后不刷盘，由操作系统的定时机制进行刷盘。对性能影响最小，数据安全性低

命令重写机制

• 过期的数据不再写入文件
• 无效的命令不再写入文件。如重复设置某个值，或数据已经被删除
• 多条命令合并为一条命令。比如push list a; push list b 两条命令，就可以合并为push list a b 这一条命令;

触发命令重写

1. 手动触发

  直接调用 bgrewriteaof命令

2. 自动触发，满足以下两个条件

  auto-aof-rewrite-min-size：AOF 文件体积最小多大以上触发

  auto-aof-rewrite-percentage：AOF 文件距离上次文件增长超过多少百分比 = 当前AOF大小 / 上次重写时AOF的大小

优缺点

  优点 是数据更完整。缺点 文件体积大，加载慢，磁盘IO高。