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两份数据文件的数据就同步了