Redis持久化问题详解

一、Redis 持久化 – AOF

1、AOF - 将每条写命令追加至 aof 文件，当重启时会执行 aof 文件中每条命令来重建内存数据

2、AOF 日志是写后日志，即先执行命令，再记录日志

        Redis 为了性能，向 AOF 记录日志时没有对命令进行语法检查，如果要先记录日志，那么日志里就会记录语法错误的命令

3、记录 AOF 日志时，有三种同步策略

①Always，同步写，日志写入磁盘再返回，可以做到基本不丢数据，性能不高

        为什么说基本不丢呢，因为 aof 是在 serverCron 事件循环中执行 aof 写入的，并且这次写入的上一次循环暂存在 aof 缓冲中的数据，因此最多还是可能丢失一个循环的数据

②Everysec，每秒写，日志写入 AOF 文件的内存缓冲区，每隔一秒将内存缓冲区数据刷入磁盘，最多丢一秒的数据

③No，操作系统写，日志写入AOF 文件的内存缓冲区，由操作系统决定何时将数据刷入磁盘

二、Redis 持久化 – AOF 重写 

（1）AOF 文件太大引起的问题

        1.文件大小受操作系统限制

        2.文件太大，写入效率变低

        3.文件太大，恢复时非常慢

（2）AOF 重写

1.重写就是对同一个 key 的多次操作进行瘦身

        ①例如一个 key 我改了 100 遍，aof 里记录了100 条修改日志，但实际上只有最后一次有效

        ②重写无需操作现有 aof 日志，只需要根据当前内存数据的状态，生成相应的命令，记入一个新的日志文件即可

        ③重写过程是由另一个后台子进程完成的，不会阻塞主进程

2.当 AOF 重写发生时

        ①创建子进程时会根据主进程生成内存快照，只需要对子进程的内存进行遍历，把每个 key 对应的命令写入新的日志文件（即重写日志）

        ②此时如果有新的命令执行，修改的是主进程内存，不会影响子进程内存，并且新命令会记录到 `重写缓冲区` 

        ③等子进程所有的 key 处理完毕，再将 `重写缓冲区` 记录的增量指令写入重写日志

        ④在此期间旧的 AOF 日志仍然在工作，待到重写完毕，用重写日志替换掉旧的 AOF 日志

三、Redis 持久化 – RDB  

（1）RDB - 是把整个内存数据以二进制方式写入磁盘

        对应数据文件为 `dump.rdb`

        好处是恢复速度快

（2）相关命令有两个

1.save - 在主进程执行，会阻塞其它命令

2.bgsave - 创建子进程执行，避免阻塞，是默认方式

        子进程不会阻塞主进程，但创建子进程的期间，仍会阻塞，内存越大，阻塞时间越长

        bgsave 也是利用了快照机制，执行 RDB 持久化期间如果有新数据写入，新的数据修改发生在主进程，子进程向 RDB 文件中写入还是旧的数据，这样新的修改不会影响到 RDB 操作

        但这些新数据不会补充至 RDB 文件

（3）缺点： save 参数可以控制 rdb 的执行周期，但这个周期不好把握

        频繁执行影响性能

        偶尔执行，如果宕机又容易丢失较多数据

四、Redis 持久化 – 混合持久化 

（1）从 4.0 开始，Redis 支持混合持久化，即使用 RDB 作为全量备份，两次 RDB 之间使用 AOF 作为增量备份

        1.配置项 aof-use-rdb-preamble 用来控制是否启用混合持久化，默认值 no

        2.持久化时将数据都存入 AOF 日志，日志前半部分为二进制的 RDB 格式，后半部分是 AOF 命令日志

        3.下一次 RDB 时，会覆盖之前的日志文件

（2）优缺点

        1.结合了 RDB 与 AOF 的优点，恢复速度快，增量用 AOF 表示，数据更完整（取决于同步策略）、也无需 AOF 重写

        2.与旧版本的 redis 文件格式不兼容