redis持久化 – 两种方式
redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
官方建议：两种方式都打开，同时进行备份。耐久性不高的可以选快照 RDB。
RDB：就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
优点：备份文件体积小，恢复速度快，fork子进程不影响父进程io；
缺点：故障时丢失数据会多点，数据集庞大时，因fork进程慢，导致客户端响应延迟；
配置：save 600 1，默认为dump.rdb（CONFIG GET save && CONFIG GET dir .....）
AOF：就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了，类似于mysql的binlog。根据fsync策略查找缓存指令记录
优点：数据完整型好，体积过大时会自动重写(将100条写入变为1条set)，采用redis协议易读懂；
缺点：文件体积大，恢复较慢，存在fsync策略导致速度较慢；
配置：appendonly yes，默认文件名appendonly.aof （CONFIG GET appendonly）；
恢复：比如执行了flushall，将备份文件中此条删除，重启即可。
注：重写，Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令；2.4 则可以自动触发 AOF 重写。
AOF文件出错：（redis重启时会拒绝载入aof文件）
a、备份现有的aof文件
b、# redis-check-aof --fix 命令行执行对现有aof文件进行修复
c、对比两个aof文件区别，重启服务器，载入修复后的aof备份文件
同时使用两种备份策略，redis重启情况下，默认aof优先，因为数据完整性高。
关闭使用两种备份策略，redis就成内存数据库了，和memcache一样。
主从备份：
架构及原理：一主可以多从，从也可以配多从；
1、从连接到主服务器后，发送sync指令；
2、主接到sync指令后，开始执行bgsave，将命令写入缓冲区；
3、bgsave结束后，主将保存得到的.rdb快照文件发给所有从，期间继续记录写操作，telnet可验证；
4、从丢弃旧的快照，载入新的快照。完毕后，主继续发送缓冲区的写指令，从进行增量备份。
配置：从服务器设置如下（当然也可以在redis内部修改，但建议还是修改配置文件）
slaveof 192.168.1.1 6379 //配置主的IP 和端口
masterauth <password> //配置主的密码
slave-read-only yes //让从只读，2.4以后默认就是只读
repl-ping-slave-period 10 //设置slave向master发起ping的频率，每10s发起一次
再详细的配置，见redis章节。
同步策略：
策略是，首先会尝试进行增量同步，如不成功，要求从机进行全量同步，之后进行增量同步。