Redis持久化总结

Redis支持RBD和AOF两种持久机制，持久化功能有效地避免了因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件可实现数据恢复。

Redis RDB持久化

RDB持久化是把当前进程数据生成快照保存到硬盘的过程。
缺点：

• 内存数据的全量同步，数据量大会由于I/O严重影响性能
• 可能会因为Redis挂掉而丢失从当前最近一次快照期间的数据

触发机制

• save命令： 阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上不建议使用
• bgsave命令： Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

自动触发RBD持久

• -使用save相关配置：如“save m n”。表示m秒内数据集存在n次修改时自动触发bgsave。
• 如果从节点执行全量复制操作，主节点自动执行bgsave生成RBD文件并发送给从节点。
• 执行debug reload命令重新加载Redis时，也会自动触发save操作
• 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave

Copy-on-Write

子进程期间使用copy-on-write机制与父进程共享内存，避免内存消耗翻倍。如果有多个调用者同时要求相同的资源（如内存或磁盘上的存储），他们会共同获取相同的指针指向相同的资源，知道某个调用者试图修改资源时，系统才会真正复制专份给该调用者，而其他调用者所见到的最初资源仍然保持不变。

Redis AOF持久化

AOF(append only file) 持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性。目前已是Redis持久化的主流方式。

日志重写如何解决AOF文件大小不断增大的问题？

• 调用fork，创建一个子进程
• 子进程把新的数据写进一个临时的AOF文件，不依赖原来的AOF文件
• 子进程持续将新的变动同时写到AOF和内存中。即使Redis意外故障也会使得数据丢失
• 主进程获取子进程重写AOF完成信号，往新AOF同步增量变动
• 使用新的AOF文件替换旧的AOF文件

RDB和AOF混合持久化

由于RDB和AOF 都各有优缺点，为了性能总体提升，可以采用RDB和AOF混合持久化。

• RDB
  优点：全量数据快照，文件小，恢复快。
  缺点：无法保存最近一次快照之后的数据
• AOF
  优点：可读性高，适合保存增量数据，数据不易丢失
  缺点：文件体积大，恢复慢

解决办法

BGSAVE做镜像全量持久化，AOF做增量持久化