Redis的持久化RDB和AOF

Redis的持久化机制

    为什么需要持久化机制，redis虽然是一个内存数据库，但是支持RDB和AOF两种持久化机制，RDB是基于快照的持久化，AOF基于日志，将数据持久化到磁盘，可以有效避免因进程退出导致的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

RDB

    RDB的持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

触发机制

1. 手动触发，对应save和bgsave命令：
   save: 阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，线上环境不建议使用。
   bgsave: Redis进程会fork出一个子进程，RDB的持久化过程由子进程负责，完成后自动结束。阻塞只发生到fork阶段，一般时间很短。

   bgsave是针对save命令导致阻塞问题做的优化。因此Redis内部所涉及到的RDB操作都是采用bgsave方式。

2. 自动触发
   redis内部存在集中自动触发RDB持久化的机制，场景如下:

   1. 配置文件中配置 save m n 代表m秒内发生n次修改时，自动触发bgsave.
   2. 当从节点执行全量复制操作，主节点自动执行bgsave生产RDB文件，发送给从节点进行数据的同步。
   3. 当使用shutdown 来停止redis服务时，如果没有开启aof的持久化，会自动触发一次bgsave操作。
   4. 当使用debug reload命令重新加载Redis时，会自动触发save操作。

   关闭RDB持久化机制,redis配置文件中save配置为 save ""来关闭。

bgsave的执行流程

1. 执行bgsave命令，父进程会判断是否存在其他子进程正在执行，如RDB/AOF子进程，如果存在，bgsave直接返回。
2. 若不存在其他子进程，则会执行fork操作来创建子进程，fork操作会阻塞父进程，通过info status 命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
3. 父进程执行fork完成后，bgsave命令返回Background saving started信息，并不再阻塞父进程，父进程继续相应redis其他命令。
4. 子进程进行RDB文件的创建，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以查看最后一次生产RDB的时间，对应info统计的rdb_last_save_time选项。
5. 子进程发送信号给父进程表示完成。父进程更新统计信息，具体见info Persistence 下的rdb_*相关选项。

RDB文件

    RDB文件保存到dir配置的指定目录下，文件名通过bdfilename配置指定。可以通过执行config set dir {newdir} 和 config set bdfilename {newbdfilename}运行期间进行配置，下次生成RDB时生效。
    Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可通过参数config set rdbcompression {yes|no} 来动态修改，虽然压缩会消耗cpu，但是可以大幅度减少文件的体积，方便保存到磁盘和网络上传输，因此建议开启。
    当redis加载损坏的RDB文件时拒绝启动，并打印如下日志:
# Short read or OOM loading DB.Unrecoverable error, aborting now.
可通过使用Redis提供的redis-check-dump 工具检查RDB文件并获取对应的错误报告。

RDB的优缺点

优点：

1. RDB是一个紧凑的二进制文件，代表Redis在某个时间点上的数据快照，非常适合用来备份，全量复制等场景。
2. Redis加载RDB文件恢复数据的数据远远快于AOF的方式。

缺点：

1. RDB方式数据无法做到实时持久化，秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁操作执行成本较高。
2. RDB文件采用特定二进制格式保存，Redis版本演进过程中会出现低版本Redis服务无法兼容新版本RDB文件格式的问题。
   针对 RDB不适合实时持久化的问题，Redis使用AOF持久化操作解决。

AOF

    AOF持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令以恢复数据。AOF的主要作用是为了解决数据的实时持久化，目前是Redis主流的持久化方式。
    使用AOF的方式比较简单，需要在配置文件中appendonly yes默认不开启，appendfilename=appendonly.aof来指定AOF文件的名称，目录和RDB一样使用dir指定的目录。分为4个步骤，append 文件写入，sync 保存到磁盘，rewrite 重写命令，重启加载。

AOF步骤

1. 追加命令到aof_buf(aof缓冲区)。
2. aof缓冲区根据一定的策略来把命令持久化到磁盘。
3. 随着aof文件的越来越大，会定期进行重写来压缩。
4. 服务重启时，读取aof文件并执行来恢复数据。

缓存刷新入磁盘的配置方式：
appendfsync alawy | everysec | no 分别为 append命令后调用操作系统fsync写入磁盘 | 操作系统专门的线程每秒调用一次fsync 不调用fsync。
TIPS:系统调用 write 和 fsync 说明
write 操作会触发延迟写(delayed write)机制。Linux 在内核提供页缓冲区用来 提高硬盘 IO 性能。write 操作在写入系统缓冲区后直接返回。同步硬盘操作依赖 于系统调度机制，例如:缓冲区页空间写满或达到特定时间周期。同步文件之前， 如果此时系统故障宕机,缓冲区内数据将丢失。
fsync 针对单个文件操作(比如 AOF 文件)，做强制硬盘同步，fsync 将阻塞直 到写入硬盘完成后返回,保证了数据持久化。
建议的配置的 everysec