上篇我们主要从分析了redis的线程模型，本篇我们来看看redis的持久化。
一起探讨redis持久化
为什么要持久化
前面说过redis是一个内存数据库，那东西放在内存好好的为什么要持久化呢？想想如果宕机了咋办，重启一下，啥也没了，雪崩了，所有的流量打到DB，后果难以想象。关于缓存雪崩、穿透、击穿的话题后面的文章会讲到，谢谢大家。
怎么持久化
启动redis
./redis-server /usr/local/redis-5.0.8/etc/redis.conf
3473:C 10 Apr 2020 21:36:52.521 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
3473:C 10 Apr 2020 21:36:52.521 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=3473, just started
3473:C 10 Apr 2020 21:36:52.521 # Configuration loaded
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set rdbvalue value
OK
127.0.0.1:6379> shutdown
not connected> quit
客户端主动shutdown的时候会主动保存一次dump.rdb
save 900 1
save 300 10
save 60 10000
save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save “” 的注释打开，下面三个注释。
RDB有阻塞式save（不能接受其他命令）和非阻塞式bgsave（Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责）
优势
1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势
1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，如果不采用压缩算法(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
3、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)
企业中一般会每天夜间拷贝一份rdb文件到另一台主机以备容灾，文件名字为当天日期
RDB如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，那怎么办。
我们了解一下另一种持久化方式AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
看，已经有命令追加在aof文件里面了。
appendonly：是否打开 AOF 持久化功能
appendfilename：AOF 文件名称
appendfsync：同步频率
对于同步频率有三种方式
always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；
everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；
no：不同步到硬盘（让操作系统来决定何时进行同步）。
AOF原理主要是两块
1、AOF追加网络协议格式的文本内容
aof_buf来延迟同步磁盘，加快相应。
always阻塞式同步。
everysec启用子进程同步。
2、AOF重写
合并命令，多条变一条来压缩aof文件。
aof_rewrite_buf保证当前正在执行的命令也不丢失
子进程重写，只有在下面a、b这两步阻塞主进程。
a.将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
b.对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。
这两种方式选哪一种呢？？？
企业中一般同时使用，你单独用RDB你会丢失很多数据，你单独用AOF，你数据恢复没RDB来的快，真出什么时候第一时间用RDB恢复，然后AOF做数据补全。
持久化虽然保证了单机宕机后的恢复能力，但是仍然会导致一段时间服务不可用。那该如何是好呢？
