持久化的作用
Redis所以数据保存在内存中，对数据的更新将异步保存到磁盘中。
持久化方式
主流数据库的持久化方式
快照比如MySQL的Dump，Redis的RDB
写日志比如 MySQL的binlog,Hbase的HLog，Redis的AOF
RDB
RDB是Redis内存到硬盘的快照，用于持久化，文件采用二进制文件保存在硬盘中。
触发机制
save(同步） client端发送save命令，则生成一个RDB文件，因为是同步命令，在数据量比较大的时候可能会造成阻塞。如果存在老的RDB文件，新替换老文件。复杂度为O（n）
bgsave(异步） bgsave的过程中，redis可以正常响应客户端，文件的保存策略和save一样。一般fork的时间很短，在fork的时候也会阻塞。
save vs bgsave
自动配置，满足条件就会被执行
dbfilename经常使用dump-${port}.rdb
dir选择一个合适的路径
bgsave-error遇到错误停止 rdbcompression rdb压缩，rdbchecksum 校验和 这三个选yes
rdb的触发机制
- 全量复制，主从复制
- debug reload， debug级别的重启
- shutdown
缺点
- 耗时，耗性能
- 不可控，容易丢失数据
AOF
根据日志原理，日志宕机后可以通过aof恢复。
三种策略
always 写命令刷新到缓冲区，缓冲区always fsync到磁盘中
everysec everysec
no 操作系统决定什么时候刷
如set 多次，他会合并成一条，set 最终值，这样可以减少磁盘占用和加快恢复速度。
AOF使用命令（bgrewriteaof命令）或者满足配置条件都会重写文件
bgrewriteaof命令 ， 类似于bgsave,也是fork一个子进程
auto-aof-rewrite-min-size aof文件重写需要的尺寸
auto-aof-rewrite-percentage aof文件增长率
aof_current_size aof当前尺寸
aof_base_siez aof上次启动和重写的尺寸
取舍和选择
RDB适合备份数据，AOF设置everysec 每秒刷盘，只丢失一秒数据。
常见问题
Fork操作如果卡主，会阻塞redis，与内存量息息相关，内存越大耗时越长。
CPU开销，RDB和AOF文件生成属于CPU密集型，部署应注意不和CPU密集型部署在一起。
内存开销，fork的时候linux copy-on-write机制，如果没有什么写入，消耗并不大。
硬盘开销，aof和rdb文件写入，可以结合iostat,iotop分析，不用和硬盘高负载服务部署在一起（存储服务、消息队列等）no-appendfsync-on-rewrite = yes (重写期间不追加,减少内存开销）。