redis持久化�C两种方式

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章节。

同步策略：

策略是，首先会尝试进行增量同步，如不成功，要求从机进行全量同步，之后进行增量同步。