1. 持久化配置
代码语言：javascript复制# 根据实际业务场景去合理的修改RDB文件的生成策略
save 900 1
save 300 10
save 60 10000
# 打开AOF持久化策略
appendonly yes
# fsync的频率调整为everysec是生产上最常用的策略
appendfsync everysec
# AOF rewrite 策略也需要根据实际的业务场景和数据量去修改
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb2. 企业级数据备份方案
我们通常使用RDB文件作为冷备文件，关于AOF和RDB两种备份方式的说明可以参考详解 redis-4.x 持久化机制，备份思路如下：
- 每小时 copy 一次最新的 RDB 文件到小时级别目录例如 2019-02-15-11 下，仅仅保留最近48小时的备份
- 每天 copy 一次最新的 RDB 文件到天级别的目录例如 2019-02-15 下，仅仅保留最近一个月的备份
- 每天晚上0点将当前服务器上所有的数据备份发送到远程的云服务器上。
具体实现步骤如下：
- 编写小时级别的备份方案脚本，内容如下：
[hadoop@node01 bin]$ vim redis-bak-hour.sh
#!/bin/bash
# 获取当前日期，格式为yyyy-MM-dd-HH
bak_hour=`date %Y-%m-%d-%k`
rm -rf /home/hadoop/data/redis/6379/bak/$bak_hour
# 创建对应的目录
mkdir -p /home/hadoop/data/redis/6379/bak/$bak_hour
# 复制最新的RDB文件到最新的小时级别的目录下
cp /home/hadoop/data/redis/6379/dump.rdb /home/hadoop/data/redis/6379/bak/$bak_hour/
# 删除48小时之前的备份目录
del_hour=`date -d -48hour %Y-%m-%d-%k`
rm -rf /home/hadoop/data/redis/6379/bak/$del_hour- 编写天级别的备份方案脚本，内容如下：
[hadoop@node01 bin]$ vim redis-bak-day.sh
#!/bin/bash
# 获取当前日期，格式为yyyy-MM-dd
bak_day=`date %Y-%m-%d`
rm -rf /home/hadoop/data/redis/6379/bak/$bak_day
# 创建对应的目
mkdir -p /home/hadoop/data/redis/6379/bak/$bak_day
# 复制最新的RDB文件到最新的天级别的目录下
cp /home/hadoop/data/redis/6379/dump.rdb /home/hadoop/data/redis/6379/bak/$bak_day/
# 删除一个月之前的备份数据
del_day=`date -d -1month %Y-%m-%d`
rm -rf /home/hadoop/data/redis/6379/bak/$del_day- 使用crontab定时任务，每小时执行一次 redis-bak-hour.sh 脚本，每天执行一次 redis-bak-day.sh 脚本
[hadoop@node01 bin]$ crontab -e
0 * * * * sh /home/hadoop/apps/redis-4.0.12/bin/redis-bak-hour.sh
0 0 * * * sh /home/hadoop/apps/redis-4.0.12/bin/redis-bak-day.sh- 每天晚上0点将当前服务器上所有的数据备份发送到远程的云服务器上，这里不再赘述了。
3. 企业级数据恢复方案
(1) 如果 redis 进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据，最多丢失一秒的数据。
(2) 如果 redis 进程所在机器挂掉，那么重启机器后，尝试重启redis进程，如果AOF文件没有破损，可以直接基于AOF日志文件进行数据恢复，如果AOF文件破损，那么修复AOF文件后再启动redis进程。
(3) 如果redis当前最新的AOF和RDB文件出现了丢失或者无法修复，那么可以尝试基于该机器上的最新的备份RDB文件进行数据恢复，这里需要注意的是，由于我们配置了同时使用AOF和RDB方式进行持久化，所以当把一个RDB文件移动到redis持久化目录下，然后启动redis服务后，此时redis不会使用RDB文件进行数据恢复，而是生成一个空的AOF文件，基于空的AOF文件进行数据恢复，因为当AOF文件和RDB文件同时存在时，会基于AOF文件进行数据恢复，于是即使存在一份RDB文件，进行恢复后，redis的内存中也是什么都没有。在redis进程挂掉，并且持久化目录下的AOF文件和RDB文件都丢失的情况下，正确的恢复步骤是：
- 修改redis配置文件，将appendonly改为no
- 把最新的一份备份的RDB文件复制到redis持久化目录下
- 启动redis服务，等到redis基于RDB文件恢复数据后，正常停止redis服务
- 修改redis配置文件，将appendonly改为yes
- 再次启动redis服务
(4) 如果当前机器上的所有RDB备份文件全部损坏，那么从远程的云服务器上拉取最新的RDB快照来恢复数据
(5) 如果是发现有重大的数据错误，比如某个小时上线的程序一下子将数据全部污染了，数据全错了，那么可以选择某个更早的时间点，对数据进行恢复，例如，12点上线了代码，发现代码有bug，导致代码生成的所有的缓存数据（都是脏数据），写入了redis，那么找到一份11点的RDB文件进行恢复即可。
