本文链接：http://www.cnblogs.com/zhenghongxin/p/9050219.html
- 使用两种备份方案
备份方案选择RDB和AOF同时进行备份，必须打开AOF的持久化机制，除非能接受在故障环境下丢失几分钟的数据。
在redis重启的时候，是优先通过AOF进行数据恢复的，因为AOF数据比较完整。
- RDB的生成策略
要修改的是该条命令：
save 60 10000
该条命令是60秒内，如果有1万条命令执行，那么就进行快照备份。这个值略大，可以根据自己的业务量而定，可以调小至1000。但也同时意味着，在一分钟内，如果命令执
行了999条，且在最后一秒redis挂掉，该分钟内的命令将会全部丢失。
注意不要用：redis-cli SHUTDOWN
这样的方式去测试，这是一种安全退出的模式，redis会安全生成dump.rdb
它的工作流程：
（1）redis根据配置自己尝试去生成rdb快照文件
（2）fork一个子进程出来
（3）子进程尝试将数据dump到临时的rdb快照文件中
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照
- AOF的生成策略
当AOF开启之后，redis每次接收到一条写命令，就会写入日志文件中，先写入系统的 os cache中，然后隔一段时间再fsync一下。
fsync的策略有三种：
always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低;
如果说确保说redis里的数据一条都不丢，那就只能这样了
everysec: 每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的
no：就是直接写入os cache就不管了，让linux自带的机制去将数据刷入磁盘，这样很不可控
因此我们要配置为everysec。
接着配置两条命令：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
redis 2.4之前，还需要手动，开发一些定时任务脚本，通过BGREWRITEAOF命令去执行AOF rewrite，但是redis 2.4之后，会自动进行rewrite操作
也就是说在上一次AOF rewrite之后，日志大小是128mb，接着再往里面写日志，当总日志大小增长的比例，超过了之前的100%，即达到256mb后，就会触发rewrite操作。
注意，此时还要跟 auto-aof-rewrite-min-size 比较大小，256M 大于 64m，可以触发rewrite操作。这两条命令，可以根据业务进行调节大小，或者保持默认值
- 定时任务备份方案（重要）
并不是说让redis自动进行持久化备份就可以的，而是要另开脚本，进行更细致的备份。
1 ）每小时都copy一份rdb的备份，到一个目录中去，仅仅保留最近48小时的备份
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
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` # 48小时前的目录文件名
rm -rf /usr/local/redis/snapshotting/$del_date # 删除48小时前的目录
2 ）每天copy一次备份
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.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 //备份cp
del_date=`date -d -1month +%Y%m%d` #仅保留近一个月的数据
rm -rf /usr/local/redis/snapshotting/$del_date #删除
3）每天一次将所有数据上传一次到远程的云服务器上去
原理跟第2点一样，只是不是用cp，而是用scp或rsync等命令将文件备份到远程安全服务器
以上只给了rdb的备份，aof的备份脚本基本一致。
- 数据恢复方案（重要）
（1）如果是redis进程挂掉，那么重启redis进程即可，直接基于AOF日志文件恢复数据
（2）如果是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复
如果AOF没有破损，可以直接基于AOF恢复的
AOF append-only，顺序写入，如果AOF文件破损，那么用redis-check-aof fix
（3）如果redis当前最新的AOF和RDB文件出现了丢失/损坏，那么可以尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复
找到RDB最新的一份备份，小时级的备份可以了，小时级的肯定是最新的，copy到redis里面去，就可以恢复到某一个小时的数据
（4）如果当前机器上的所有RDB文件全部损坏，那么从远程的云服务上拉取最新的RDB快照回来恢复数据
恢复的过程：
（1）优先用appendonly.aof去恢复数据
（2）停止redis，关闭aof （为什么要关闭？如果不关闭，启动redis后，redis会生成一份新的可能为空的aof强行覆盖目录下的aof，导致恢复失败）
（3）拷贝备份文件，重启redis
（4）命令行修改redis配置，开启aof （redis config set ）
-------------------------------------------------------------------------------------
AOF的重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Rdis进程内的数据转化为写命令同步到
新AOF文件的过程。
重写后的AOF文件为什么可以变小？有如下原因：
（1）进程内已经超时的数据不再写入文件。
（2）旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
（3）多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
（4）AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。