企业级的持久化的配置策略
在实际生产环境，RDB 和 AOF 一定都要打开，RDB 和 AOF 的配置需要根据业务的数据量决定
Redis RDB 持久化配置和数据恢复实验
RDB 持久化配置
- 自动方式
RDB 持久化在 redis.conf 文件中配置，目前配置文件存放在 /etc/redis/6379.conf，打开配置文件，添加 save 属性配置，定期生成 RDB 快照。
# 每隔15分钟，如果有超过1个key发生了变更，那么就生成一个新的dump.rdb文件 save 900 1 # 每隔5分钟，如果有超过300个key发生了变更，那么就生成一个新的dump.rdb文件 save 300 10 # 每隔1分钟，如果有超过10000个key发生了变更，那么就生成一个新的dump.rdb文件 save 60 10000
save 属性可以设置多个，就是设置多个 SNAPSHOTTING 检查点，每到一个检查点，就会去 check 一下，是否有指定的 key 数量发生了变更，如果有，就生成一个新的 dump.rdb 文件。
- 手动方式
也可以在 redis-cli 命令中输入 save 或者 bgsave 命令，手动同步或异步生成 RDB 快照。
RDB 持久化机制的工作流程
- Redis 根据配置自己尝试去生成 RDB 快照文件；
- fork 一个子进程出来；
- 子进程尝试将数据 dump 到临时的 RDB 快照文件中；
- 完成 RDB 快照文件的生成之后，就替换之前的旧的快照文件；
基于 RDB 持久化机制的数据恢复实验
通过 redis-cli SHUTDOWN 这种方式去停掉 Redis，其实是一种安全退出的模式，Redis 在退出的时候会将内存中的数据立即生成一份完整的 RDB 快照，存放在 /var/redis/6379/dump.rdb。
需要使用 kill -9 *** 强制杀死进程的方式来模拟 Redis 异常退出。执行步骤如下：
- 先往 Redis 中插入几条数据；
- kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
- 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据已经丢失；
- 配置 save 检查点，save 5 1（每隔5秒，如果有超过1个key发生了变更，那么就生成一个新的dump.rdb文件）；
- 往 Redis 中插入几条数据，暂停5秒以上；
- kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
- 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据还在，查看 dump 文件，发现已经更新为成最新的了；
Redis AOF 持久化配置和相关实验
AOF 持久化配置
AOF 持久化配置，默认是关闭的，默认打开的是 RDB 持久化配置。AOF 持久化在 redis.conf 文件中配置，目前配置文件存放在 /etc/redis/6379.conf。
打开配置文件，修改 appendonly 属性为 yes ，打开 AOF 持久化配置：
appendonly yes
AOF 有三种 fsync 策略：
# 每次写入一条数据就执行一次 fsync # appendfsync always # 每隔一秒执行一次 fsync appendfsync everysec # 不主动执行fsync # appendfsync no
- always：每次写入一条数据，立即将这个数据对应的写日志 fsync 到磁盘上去，性能非常差，吞吐量很低；
- everysec：每秒将 os cache 中的数据 fsync 到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的；
- no：Redis 只负责将数据写入 os cache 就不管了，后面 os cache 根据自己的策略将数据刷入磁盘，不可控制；
基于 AOF 持久化机制的数据恢复实验
- 设置 appendonly 属性为 yes，打开 AOF 持久化，重启 Redis；
- 往 Redis 中写入几条数据，等待一秒；
- kill -9 强制杀死 Redis 进程，删除 /var/run/redis_6379.pid 文件，再重新启动 Redis；
- 通过 redis-cli 客户端查看刚刚插入的数据，发现最新的几条数据还在，查看 /var/redis/6379 文件夹，发现已经存在appendonly.aof 文件；
AOF rewrite 操作
Redis 中的内存中的数据是有一定限量的，内存到一定大小后，Redis 就会使用缓存淘汰算法（LRU）自动将一部分过期数据从内存中清除。AOF 是存放没有写命令的，所以文件会不断膨胀，当大到一定的时候，AOF 会做 rewrite 操作。
在 redis.conf 文件中，可以配置 rewrite 策略。
# 如果 AOF 日志文件增长的比例，超过了之前的100%，就可能会去触发一次 rewrite auto-aof-rewrite-percentage 100 # 但是此时还要去跟min-size比较，大于64M才会去触发一次 rewrite auto-aof-rewrite-min-size 64mb
AOF rewrite 操作步骤：
- Redis fork 一个子进程；
- 子进程基于当前内存中的数据，构建日志，开始往一个新的临时的 AOF 文件中写入日志；
- Redis 主进程，接收到 client 新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的 AOF 文件；
- 子进程写完新的日志文件之后，Redis 主进程将内存中的新日志再次追加到新的 AOF 文件中；
- 用新的日志文件替换掉旧的日志文件；
AOF 破损文件的修复
如果 Redis 在 append 数据到 AOF 文件时，机器宕机了，可能会导致 AOF 文件破损，用 redis-check-aof --fix 命令来修复破损的 AOF 文件。
redis-check-aof --fix /usr/local/appendonly.aof
AOF 和 RDB 同时工作
- 如果 RDB 在执行 snapshotting 操作，那么 Redis 不会执行 AOF rewrite; 如果 Redis 再执行 AOF rewrite，那么就不会执行 RDB snapshotting
- 如果 RDB 在执行 snapshotting，此时用户执行 BGREWRITEAOF 命令，那么等 RDB 快照生成之后，才会去执行 AOF rewrite
- 同时有 RDB snapshot 文件和 AOF 日志文件，那么 Redis 重启的时候，会优先使用 AOF 进行数据恢复，因为其中的日志更完整
企业级的数据备份方案
- 写 crontab 定时调度脚本做数据备份
- 每小时都 copy 一份 rdb 的备份，到一个目录中去，仅仅保留最近48小时的备份
- 每天都保留一份当日的 rdb 的备份，到一个目录中去，仅仅保留最近1个月的备份
- 每次 copy 备份的时候，都把太旧的备份给删了
- 每天晚上将当前服务器上所有的数据备份，发送一份到远程的云服务上去
按小时备份
redis_rdb_copy_hourly.sh
#!/bin/sh cur_date=`date +%Y%m%d%k` rm -rf /usr/local/redis/snapshotting/$cur_date mkdir /usr/local/redis/snapshotting/$cur_date cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date del_date=`date -d -48hour +%Y%m%d%k` rm -rf /usr/local/redis/snapshotting/$del_date
每小时 copy 一次备份，删除48小时前的数据。
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
按天备份
redis_rdb_copy_daily.sh
#!/bin/sh cur_date=`date +%Y%m%d` rm -rf /usr/local/redis/snapshotting/$cur_date mkdir /usr/local/redis/snapshotting/$cur_date cp /var/redis/6379/dump.rdb /usr/local/redis/snapshotting/$cur_date del_date=`date -d -1month +%Y%m%d` rm -rf /usr/local/redis/snapshotting/$del_date
每天 copy 一次备份，删除一个月前的数据。
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh 0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
数据恢复方案
- 如果是 Redis 进程挂掉，那么重启 Redis 进程即可，直接基于 AOF 日志文件恢复数据；
- 如果是 Redis 进程所在机器挂掉，那么重启机器后，尝试重启 Redis 进程，尝试直接基于 AOF 日志文件进行数据恢复；
- 如果 Redis 当前最新的 AOF 和 RDB 文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的 RDB 数据副本进行数据恢复；
恢复步骤参考如下：
- 停止 Redis
- 在 Redis 配置文件中关闭 AOF 持久化配置
- 拷贝云服务上最新的 RDB 备份数据到 /var/redis/6379 文件夹下
- 重启 Redis，确认数据恢复
- 直接在命令行热修改 Redis 配置，config set appendonly yes
- 确认在 /var/redis/6379 文件夹下生成 AOF 持久化文件 appendonly.aof
- 停止 Redis
- 在 Redis 配置文件中打开 AOF 持久化配置
- 重启 Redis，确认数据情况
- 如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据
- 如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复
举个例子，12点上线了代码，发现代码有 bug，导致代码生成的所有的缓存数据全部错了，找到一份11点的 rdb 的冷备，然后按照上面的步骤，去恢复到11点的数据，就可以了。
