持久化就是将数据的更新异步的保存到磁盘中
持久化方式：
1、快照：某个时间点数据的备份 MySQL dump、Redis RDB
2、写日志：MySQL BinLog、HBASE Hlog、Redis AOF
只针对Redis两种持久化方式进行介绍，RDB和AOF可以使用一种、两种，甚至都不使用
持久化配置选项：
#RDB持久化选项 #save 900 1 //900s有一次写入 #save 300 10 //300s有10次写入 #save 60 10000 //60s中有10000次写入 stop-writes-on-bgsave-error no //创建快照失败后是否继续执行写命令 rdbcompression yes //知否对快照文件进行压缩 dbfilename "dump_6379.rdb" //快照文件名 #AOF持久化选项 appendonly yes //是否使用AOF持久化 appendfilename "appendonly.aof" //AOF文件名称 appendfsync everysec //多久将写入内容同步到硬盘 no-appendfsync-on-rewrite no //对AOF进行重写时，是否执行同步操作 auto-aof-rewrite-percentage 100 //多久执行一次AOF压缩 auto-aof-rewrite-min-size 64mb dir "/var/local/redis/data" //共享选项，决定了RDB和AOF文件的保存位置
RDB
工作原理：快照snapshotting
Redis创建RDB文件以二进制的形式保存在磁盘中，将存在于某一时刻的所有数据写入磁盘，然后就可以通过这个RDB文件恢复数据（启动载入）
在创建快照之后，用户可以对快照进行备份，复制到其他服务器从而创建具有相同数据的服务器副本。
创建RDB文件的方式：
1、save（同步）：可能会发生阻塞，数据量很大时，如果存在老文件，会发生替换
2、bgsave（异步）：通过fork()创建一个子进程去生成RDB文件，fork()执行很快的，极小的情况下才会发生阻塞
3、自动：触发某些条件，内部执行了bgsave生成RDB文件
当满足任意条件的时候就会触发BGSAVE命令
#save 900 1 //900s有一次写入 #save 300 10 //300s有10次写入 #save 60 10000 //60s中有10000次写入
对默认配置进行优化修改：右边是修改后
save 900 1 #save 900 1 save 300 10 #save 300 10 save 60 10000 #save 60 10000 dbfilename dump.rdb dbfilename dump-${port}.rdb dir ./ dir /bigdiskpath
4、主从复制，全量复制也会产生RDB文件
5、debug reload debug级别的重启，不需要将内存清空
6、shutdown
缺点：
1、耗时（将内存中数据进行dump 时间复杂度O(N)）
2、消耗内存：fork()，copy-on-write策略
3、Disk I/O：IO性能
4、不可控，丢失数据，T3到T4之间数据丢失了，或者使用save、bgsave的定时任务，存在同样的问题
异常场景：
T1 执行多个写命令
T2 满足RDB自动创建的条件
T3 再次执行多个写命令
T4 宕机
这时候就会丢失T2到T4之间的数据，所以，RBD方式只适用于哪些即使丢失一部分数据也不会造成问题的应用程序
AOF
AOF持久化就是将被执行的写命令写到AOF文件的末尾，一次来记录数据发生的变化。
策略：
1、always：
2、everysec：一般使用这个
3、no：OS控制
我们使用everysec的策略，使我们丢失数据的时间窗口降低至1s（甚至不丢失数据），但是随着Redi不断运行，aof文件的体积会变得很大，甚
至会用完磁盘空间，而且文件体积过大，在进行还原操作的时间会很长。
为了解决AOF文件体积增大的问题，出现了AOF重写
AOF重写：
为了减少磁盘占用量、加速恢复速度
原生AOF AOF重写 set hello world set hello hehe set hello java set counter 2 set hello hehe rpush mylist a b c incr counter incr counter rpush mylist a rpush mylist b rpush mylist c
删除过期数据
AOF重写实现方式：
1、bgrewriteaof命令：fork()出一个子进程，然后通过内存进行AOF重写出一个AOF文件,而不是通过原来的AOF文件去重写
2、AOF重写配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
通过上面两个参数，能够自动执行BGREWRITEAOF。
上面100和64mb代表着，当AOF文件体积大于64MB，并且AOF文件的体积比上次重写之后的体积打了至少100%的时候，将执行BGREWRITEAOF命令
| 命令 | RDB | AOF |
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 轻 | 重 |
RDB最佳策略：
1、最好选择把RDB"关闭"，主从复制的时候需要主节点的RDB文件传给子节点
2、集中管理：按天、星期等备份是个不错的选择，文件比较小
3、主从，从开
4、注意save发生的频率不要很频繁
AOF最佳策略：
1、"开"：缓存和存储，只是进行缓存的场景是可以关闭的
2、AOF重写集中管理：单机多部署的时候，针对集中发生fork，所以一个机器70%的内存分配给Redis
3、同步频率为everysec
最佳策略：
1、小分片：通过maxmemory进行设置，例如最大内存设置4G
2、缓存或存储
3、监控（硬盘、内存、负载、网络）
4、足够内存
fork操作：
1、是同步操作，会阻塞Redis
2、和内存量相关：内存越大，耗时越大（物理机和虚拟机也有差别，物理机性能更好）
3、info:latest_fork_usec 查看fork执行时间
改善fork操作：
1、优先使用物理机或支持高效fork操作的虚拟技术
2、设置Redis的最大使用内存：maxmemory
3、合理配置Linux内存分配策略：vm.overcommit_memory=1 默认0
4、降低fork频率：放宽AOF重写的触发规则，减少不必要的全量复制
fork产生的子进程开销和优化：
1、CPU：
开销：RDB和AOF文件产生，属于CPU密集型操作
优化：不做CPU绑定，不和CPU密集型部署
2、内存
开销：fork产生子进程内存开销，copy-on-write（当父进程有写操作时，会产生一个副本，这时候才会消耗较多内存）
3、硬盘
开销：AOF和RDB文件的写入，可以结合iostat，iotop分析
优化：
1).不要和存储服务、消息队列这种高负载服务部署在一起
2).no-appendfsync-on-rewrite = yes
3).根据写入量决定磁盘类型：例如使用机械硬盘
4).单机多部署的时候持久化文件目录可以分盘