Redis持久化机制:

RDB快照
AOF日志

一. RDB快照

1.概念

RDB是把当前进程数据生成快照保存到硬盘的过程(以二进制方式写入磁盘)

2.触发机制: 手动和自动

【1】手动触发分别对应save和bgsave命令

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

【2】自动触发就是在配置文件中使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave

3.优缺点

产生的文件小，恢复速度快, 由于每次生成RDB开销较大(需要fork子进程,属于重量级操作,会导致redis卡顿若干秒)，无法做到实时持久化

4.禁用持久化

命令 config set save ""

二. AOF日志

1.概念

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

2.开启方式

查询aof是否开启: 
命令 config get appendonly

开启AOF:
1)命令行(实时生效,但重启后失效):
config set appendonly

2)配置文件(需重启生效):
appendonly yes，默认不开启

3.触发策略

手动触发:
执行命令 bgrewriteaof

3种自动触发:
（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失(推荐)
（3）不同no：从不同步

4.AOF工作流程

1.所有写入命令追加到aof_buf缓冲区(redis是单线程响应命令,如果每次命令都直接追加到磁盘,会影响磁盘的负载)

2.aof缓冲区根据对应的策略向磁盘做同步操作

3.随着aof文件越来越大,需要定期对aof文件进行重写,达到压缩目的

4.redis重启时,可以加载aof文件进行数据恢复

5.AOF重写机制

原因: 
AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多.当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩

重写原理: 
Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中...最后替换旧的aof文件

触发机制：
当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改

手动触发：
直接调用bgrewriteaof命令。
自动触发：
根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。
·auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。
自动触发时机=aof_current_size > auto-aof-rewrite-minsize &&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage

三. RDB和AOF同时开启可能存在的坑

场景: 如果redis以rdb模式运行了,然后关闭redis,配置文件配置开启aof,重启redis,此时会发现redis中没有数据

原因: redis会优先基于aof去恢复,,即使没有.aof文件,,他会创建一个新的空的.aof文件....

解决方案:
停止redis，关闭aof，拷贝rdb备份，重启redis，确认数据恢复，
直接在命令行热修改redis配置(redis的客户端执行命令:    config set appendonly yes)，打开aof，
这时redis就会将内存中的数据对应的日志，写入aof文件中, 此时aof和rdb两份数据文件的数据就同步了