Redis持久化（数据备份与恢复）
- 持久化的概念
what：利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。
why：防止数据的意外丢失，确保数据安全性
how：RDB 和 AOF
持久化过程保存什么？
（1）将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
数据（快照）
RDB
（2）将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程
过程（日志）
AOF - RDB
（1）RDB启动方式
方式一：save指令，手动执行一次保存操作，会在配置文件指定目录中生成dump.rdb文件
dir ./ #数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dbfilename dump_6379.rdb #指定rdb文件的名称
注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
恢复实验步骤：【redis启动时会恢复备份文件中数据】
# 先存进一个字符串
192.168.40.130:6379>set czx czx
# 备份
192.168.40.130:6379>save
# 将备份文件备份到另一个目录（否则redis会覆盖）
[aaa@qq.com ~]#cp /home/redis/dump_6379.rdb dump_6379.rdb
# 将redis中的czx给删除了
192.168.40.130:6379>del czx
# 结束redis进程
[aaa@qq.com ~]# 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
[aaa@qq.com ~]# kill 7470
# 关闭redis之后才能覆盖备份的rdb文件
[aaa@qq.com ~]#cp dump_6379.rdb /home/redis/dump_6379.rdb
# 启动redis服务
[aaa@qq.com ~]#service redisd start
# 获取czx键值
192.168.40.130:6379>get czx
方式二：bgsave指令，手动启动后台保存操作，但不是立即执行
注意：默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。
bgsave是主流的触发RDB持久化方式
192.168.40.130:6379>bgsave
# 可以查看备份文件大小是否改变
[aaa@qq.com ~]#ll /home/redis/dump_6379.rdb
方式三：save配置，配置文件中默认有下方三个save配置（使用的是bgsave指令）
三种方式的对比：
- 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
# 查看文件的详细信息 （要执行存储操作对比）
[aaa@qq.com ~]#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 来恢复数据，降低丢失数据的量