Redis 持久化机制

Redis持久化机制保证数据不会因为发生故障而丢失，Redis提供了两种持久化机制，RDB快照和AOF日志。

第一种，RDB快照

快照是一次全量备份，Redis是单线程，在持久化时，创建一个子进程进行bgsave快照持久化，父进程处理客户端请求。

底层使用的是操作系统的COW（copy on write）机制进行数据段页面的分离，父子进程共享内存资源，当父进程对数据段某个页面的数据进行修改时，会将这个共享的页面复制一份出来，然后对这个复制的页面进行修改，而子进程的页面从进程产生的一刻就不会发生变化了，因此被称为“快照”，子进程负责将数据写到磁盘，完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

RDB触发规则可以在配置文件中进行设置，默认开启RDB功能，配置文件里如果开启save "" 的话，会关闭bgsave功能，默认设置如下，

save 900 1  15分钟内至少一个key值发生变化
save 300 10 5分钟内有10个key值发发生变化
save 60 10000 1分钟内至少1w个key值发生变化

RDB快照文件名：
dbfilename dump.rdb
RDB快照文件路径：
dir ./

快照持久化的优点是数据恢复速度相对快，而弊端就是持久化过程中redis 宕机会导致上一个备份与当前备份之间的数据丢失；另一个问题就是数据量很大时候，fork过程会比较耗时；只有一个备份文件。

第二种，AOF日志

AOF方式是Redis 的写数据写到日志中，是连续的增量备份，这种方式好处是丢失数据少，但是恢复数据速度慢。

因为AOF日志随着Redis运行时间变得越来越大，Redis 4.0版本前会定期对AOF进行重写，包含删除抵消的命令，合并重复的命令，生成一个新的AOF文件用于代替旧的的AOF文件，保证AOF文件不会太大；Redis 4.0版本对AOF重写进行了一个优化，AOF中包含RDB全量数据，然后增量追加新的写操作，这样结合了RDB和AOF各自的优点，恢复数据快和全量。

AOF 在配置文件中也有默认的配置，

appendonly no 默认是不开启的，开启使用yes

appendfilename "appendonly.aof"

# appendfsync always  数据最可靠，立即aof，最慢
appendfsync everysec 默认每秒调一次flush，写aof
# appendfsync no  内核buffer满的话自动写aof，比always快，比everysec慢，可能会丢失一个buffer大小的数据

no-appendfsync-on-rewrite no

如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

因为快照和AOF的sync都是比较耗费资源的，一般使用两种机制持久化，使用快照做镜像全量持久化，AOF做增量持久化。

因为快照会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。

在Redis实例重启时，会使用快照持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。