五、Redis持久化（数据备份与恢复）
1. 持久化的概念
redis的持久化是将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。
redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
持久化过程保存什么？
|
10011001110000001 00101001011010110 10110011001110000 00100101001011011 数据（快照） RDB |
RDB 的优点:
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集
- RDB 非常适用于灾难恢复（disaster recovery）
- RDB 可以最大化 Redis 的性能
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
RDB 的缺点：
1)需要尽量避免在服务器故障时丢失数据, RDB 不适合, RDB 文件需要保存整个数据集的状态, 一旦发生故障停机， 你就可能会丢失好几分钟的数据
2)数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端
（1）将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
|
删除第3行 第4行末位添加字符x 删除第2到第4行 复制第3行粘贴到第5行 过程（日志） AOF |
（2）将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程
AOF 的优点:
- AOF 持久化会让 Redis 变得非常耐久
- AOF 文件是一个只进行追加操作的日志文件（append only log）
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合
- AOF 文件有序地保存了对数据库执行的所有写入操作
AOF 的缺点：
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。
- AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。
2. RDB
（1）RDB启动方式
方式一：save指令，手动执行一次保存操作，会在配置文件指定目录中生成dump.rdb文件
dir ./ #数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dbfilename dump_6379.rdb #指定rdb文件的名称
注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
恢复实验步骤：【redis启动时会恢复备份文件中数据】
# 先存进一个字符串
192.168.40.130:6379>set cjy cjy
# 备份
192.168.40.130:6379>save
# 将备份文件备份到另一个目录（否则redis会覆盖）
[root@localhost ~]#cp /home/redis/dump_6379.rdb dump_6379.rdb
# 将redis中的cjy给删除了
192.168.40.130:6379>del cjy
# 结束redis进程
[root@www ~]# ps -aux|grep redis
root 7470 0.1 0.1 39980 1872 ? Ssl 15:17 0:00 /usr/local/redis-5.0.7/src/redis-server *:6379
root 7488 0.0 0.0 112728 968 pts/0 S+ 15:19 0:00 grep --color=auto redis
[root@www ~]# kill 7470
# 关闭redis之后才能覆盖备份的rdb文件
[root@localhost ~]#cp dump_6379.rdb /home/redis/dump_6379.rdb
# 启动redis服务
[root@localhost ~]#service redisd start
# 获取cjy键值
192.168.40.130:6379>get cjy
方式二：bgsave指令，手动启动后台保存操作，但不是立即执行
注意：默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。
bgsave是主流的触发RDB持久化方式
192.168.40.130:6379>bgsave
# 可以查看备份文件大小是否改变
[root@localhost ~]#ll /home/redis/dump_6379.rdb
方式三：save配置，配置文件中默认有下方三个save配置（使用的是bgsave指令）
save 900 1 #900秒内有至少1个键被更改则进行快照；
save 300 10 #300秒内有至少10个键被更改则进行快照；
save 60 10000 #60秒内有至少10000个键被更改则进行快照。
三种方式的对比：
3. AOF
（1）RDB存储的弊端
- 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程，内存产生额外消耗
- 宕机带来的数据丢失风险
（2）解决思路
- 不写全数据，仅记录部分数据
- 降低区分数据是否改变的难度，改记录数据为记录操作过程
- 对所有操作均进行记录，排除丢失数据的风险
如果数据很重要无法承受任何损失，可以考虑使用AOF方式进行持久化，默认Redis没有开启AOF(append only file)方式的全持久化模式。
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些，开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改该名称。
Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少，可以在redis.conf中通过appendonly参数开启Redis AOF全持久化模式：
配置文件设置
appendonly yes #开启AOF持久化功能；默认是no，关闭的
appendfilename "appendonly.aof" #AOF持久化保存文件名；
# appendfsync always #每次执行写入都会执行同步，最安全也最慢；
appendfsync everysec #每秒执行一次同步操作；
# appendfsync no #不主动进行同步操作，而是完全交由操作系统来做，每30秒一次，最快也最不安全；
auto-aof-rewrite-percentage 100 #当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据；
auto-aof-rewrite-min-size 64mb #允许重写的最小AOF文件大小配置写入AOF文件后，要求系统刷新硬盘缓存的机制。
备份实验步骤：
# 开启AOF持久化功能和设置持久化保存的文件名，位置和RDB一样
appendonly yes #开启AOF持久化功能；默认是no，关闭的
appendfilename "appendonly.aof" #AOF持久化保存文件名；
修改完之后要重启redis
# 查看文件的详细信息 （要执行存储操作对比）
[root@localhost ~]#ll /home/redis/ appendonly.aof
恢复实验步骤：
（和RDB一样都是开启redis时，会加载备份文件）
4. RDB和AOF对比
选择RDB还是AOF？
对数据非常敏感，建议使用默认的AOF持久化方案
- AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。
- 注意：由于AOF文件存储体积较大，且恢复速度较慢
数据呈现阶段有效性，建议使用RDB持久化方案
- 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
- 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重使用
综合比对：
- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
- 灾难恢复选用RDB
- 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
