redis-持久化
持久化分类
AOF：将每次执行的写命令保存到硬盘
RDB：将当前进程中的数据生成快照保存到硬盘
比较：
RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。但是由于是定时快照，做不了实时持久化，可能丢失数据。
AOF的优点在于支持秒级持久化，缺点是文件大、恢复速度慢、对性能影响大。但可定时文件重写。Redis服务器默认开启RDB，关闭AOF。
但AOF比较主流，可以选择两者都开。
触发条件
手动触发：save （会阻塞）、bgsave （会fork子进程进行后续操作，只有fork子进程时阻塞）
自动触发：
1.配置文件 save m n ， 当m秒内发生n次变化时，会触发bgsave， 可以配置多个条件，任意达到一个都会触发。自动触发定时执行serverCron函数， 获取dirty计数器、和lastsave时间戳来判断。
2.主从复制时，若从节点全量复制，主节点会执行bgsave，然后将rdb文件给从节点。
3.执行shutdown命令时，自动执行rdb持久化。
加载时机
如果开启了AOF，会优先加载AOF，否则redis启动时自动加载RDB文件，加载过程中是阻塞的。若文件损坏，会导致redis启动失败。
文件重写
由于AOF文件是记录更改信息的，所以可能随着时间推移会越来越大，这个时候定期的重写AOF文件是有好处的，可以减少一些无效的命令，及合并一些分开执行的命令。比较好的方式是关闭自动重写，而采用定时任务，定时在请求量少的时候重写（bgrewriteaof）。
伪客户端
Redis服务器在载入AOF文件之前，会创建一个没有网络连接的客户端，之后用它来执行AOF文件中的命令。
关于阻塞
1.redis内存不宜超过10G，持久化的fork操作可能会过长，导致阻塞，可参考监控数据。
2.AOF追加写入的时候，比如采用everysec策略，主线程写入aof_buf返回，fsync每秒同步一次，可能由于磁盘负载过高超过1s，为保证数据少丢失，主线程会判断上一次fsync成功的时间，如果大于2s，会阻塞等待fsync完成。所以此时最多可能丢失2s的数据。
重要参数指标
执行info Persistence
rdb_last_bgsave_status：上次bgsave结果
rdb_last_bgsave_time_sec：上次bgsave耗时，单位s
aof_enabled：是否开启AOF
aof_last_rewrite_time_sec：上次重写耗时，单位s
aof_delayed_fsync：AOF追加阻塞情况的统计
执行info stats
latest_fork_usec：上次fork耗时
好的方案
1.持久化，master完全关闭持久化；slave：关闭RDB，开启AOF。（根据实际情况调整）
2.关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨3点）调用bgrewriteaof。
3.定时备份。
4.异地灾备，定时将RDB文件或重写后的AOF文件，通过scp拷贝到远程机器。
