四、redis之RDB和AOF持久化
持久化：将redis存放在内存的数据的更新异步备份到磁盘上
持久化方式：
快照：redis=》rdb、mysql=》dump
写日志：redis=》aof、mysql=》binlog
1.RDB（redis detabases）
1.1、同步快照（节省内存资源；redis服务属於单线程，所以在快照过程中会出现阻塞现象）
client发送save命令，生成rdb二进制文件
1.2、异步快照（fork一个进程备份数据出现阻塞【很快，可忽略】、消耗内存、但redis服务不会出现阻塞现象）
client发送bgsave命令，生成rdb二进制文件
1.3、自动快照（不需要客户端发送命令，redis服务根据在一定时间内改变数量判定是否需要快照。配置文件：save seconds changes）
save 900 1（900秒有1个数据改变时进行异步备份）
save 300 10（300秒有10个数据改变时进行异步备份）
save 60 10000（60秒有10000个数据改变时进行异步备份）
1.4、触发机制-不容忽略方式
全量复制
debug reload
shutdown
1.5、RDB总结
rdb时redis内存到硬盘的快照，用于持久化
save通常会阻塞redis
bgsave不会阻塞redis，但是会fork新进程
save自动配置满足任一就会被执行
有些触发机制不容忽视
耗时耗性能，不可控，丢失数据
2.AOF（append only file）
1、aof三种策略
1.1：always（redis写命令刷新到缓冲区，每条写命令都把缓冲区fsync到硬盘，即：aof文件。不会丢失数据、IO开销大）
1.2：everysec（【默认值】redis写命令刷新到缓冲区，每秒把缓冲区fsync到硬盘，即：aof文件。宕机只会丢失1秒的数据、）
1.3：no（redis写命令刷新到缓冲区，根据操作系统决定把缓冲区fsync到硬盘，即：aof文件。不用管，而不可控）
2、aof重写（把过期、重复、无效进行去除，化简）=》减少硬盘占用量，加速回复速度
2.1：bgrewriteaof
客户端发送bgrewriteaof命令，redis服务fork异步一个子进程进行aof重写
2.2：aof重写配置
2.2.1、auto-aof-rewrite-min-size（aof文件重写需要的尺寸【配置】）
2.2.2、auto-aof-rewrite-percentage（aof文件增长率【配置】）
2.2.3、aof_current_size（aof当前尺寸（单位：字节）【统计】）
2.2.4、aof_base_size（aof上次启动和重写的尺寸【单位：字节】【统计】）
自动触发时机(同时满足)：
aof_current_size > auto-aof-rewrite-min-size、
（aof_current_size - aof_base_size）/ aof_base_size > auto-aof-rewrite-percentage
3、aof配置
appendonly yes|no （打开或关闭aof持久化）
appendfilename ”appendonly-${port}.aof“（设置aof文件名称）
appendfsync everysec|always|no（aof同步策略）
dir ”保存文件地址（日志|rdb|aof文件）“
no-appendfsync-on-rewrite yes|no（aof重写时是否允许正常的aof-append操作）
auto-aof-rewrite-percentage 100（增长率）
auto-aof-rewrite-min-size 64mb（最小尺寸）
aof-load-trunted yes （是否忽略aof错误）
3、RDB与AOF区别和抉择
1.区别
启动优先级：rdb低、aof高；体积：rdb小、aof大；恢复速度：rdb快、aof慢；数据安全性：rdb丢数据、aof根绝策略而定；轻重：rdb重、aof轻；
2.抉择
小分片
缓存或者存储
监控（硬盘、内存、负载、网络）
足够的内存
4.开发运维问题
1.fork线程
1.1：同步操作
1.2：与内存息息相关：内存越大，耗时约长（与机器类型有关）
1.3：info:lastest_fork_usec（查询fork时间）
1.4：改善fork
1.4.1、有限使用物理机或者高校fork操作的虚拟技术
1.4.2、控制redis实例最大可用内存：maxmemory
1.4.3、合理配置linux内存分配策略：vm.overcommit_memory=1
1.4.4、降低fork频率：例如放跨u你AOF重写自动触发时机，不必要的全量复制
2.子进程外开销与优化
2.1：CPU
~开销：RDB与AOF文件生成，属于CPU密集型
~优化：不做CPU绑定，不和CPU密集型部署
2.2：内存
~开销：fork内存开销，copy-on-write
~优化：echo never >
2.3:硬盘
~开销：AOF和RDB文件写入，可以i结合iostat，iotop分析
~优化：不要和高硬盘负载服务部署在一起：存储服务，消息队列等；no-appendsync-on-rewrite=yes；根据写入量决定磁盘类型：例如ssd；单机多实例持久化文件目录可以考虑分盘
3.AOF追加阻塞
3.1：阻塞定位
3.1.1、redis日志
3.1.2、info Persistent（历史的累计过程）
3.1.3、通过硬盘查看使用IO情况