【RDB和AOF介绍】

众所周知，Redis支持RDB和AOF两种持久化方式（据说作者将来要将两者整合），前者就是定时快照，定时dump数据到磁盘；后者则类似于MySQL的binlog，会记录数据的每次变动动作。

两者并不冲突，可根据需求采用。

一般来说，常规情况下（绝大多数）都只是使用RDB；

性能至上的场景（类似memcache缓存）则可以完全关闭RDB和AOF；

对于对数据完整性要求极高的情况下（这种情况下一定要考虑好是不是非要用Redis）才会使用AOF，或两者都用。

【相关配置项介绍】

RDB时，对于快照的拍照频度，就是通过配置中的save 项进行设置，没啥好说的，视实际情况设置调整。

AOF时，也就是设置appendonly为yes，还需要设置的地方有：

appendfilename appendonly.aof 即aof文件的文件名。该文件增长的比较快，因为保存了每次写操作的过程，需要特别注意。

然后根据具体情况开启下面三个的其中一项，

# appendfsync always  每一步写操作都写入aof（最及时，影响性能最大）
# appendfsync everysec   每秒钟写入一次 （折中）
# appendfsync no  Redis自身不主动写入，由OS系统内核写入（最慢，效率最高）

再捡几个主要的配置项说下：

slave-serve-stale-data默认为yes，表示当slave连不上master（如master宕机）时，该slave仍然能够响应client的请求，提供服务；反之为no时，slave不继续响应client，而是返回error。

rdbcompression默认为yes，表示保存快照时会对数据进行压缩，好处是dump出的文件会变小，坏处额外增加CPU负担，若改为no则反之。这年头CPU一般不是瓶颈，尤其是对于存储设备来说，所以建议开启。

maxmemory  一定要设置最大内存，且建议最好留出一半以上的物理内存，供持久化操作及给slave同步数据用。

【数据恢复】

当Redis挂掉后，重启服务即可，此时它会自动从rdb或aof文件恢复数据到内存。

rdb文件中的数据更直接，体积小，恢复速度快；

aof文件记录的是log，体积庞大，恢复速度很慢。

如果两个文件都有，Redis会以哪个为准呢？

答：Redis在没有aof文件时才会使用rdb文件进行恢复。

【一种常规方案】

master关闭RDB和AOF；slave开启RDB，只读。

灾难场景：

1、当slave挂掉时，重启挂掉的slave即可，slave会自动和master同步；

2、当master挂掉时（只要slave没同时挂掉，如果怕就多搞几个slave），先停掉slave与master的同步（防止master重启后把未完全恢复的数据同步覆盖到slave），再把slave的rdb文件复制到master上（复制之前尽量执行一下bgsave命令，手动进行快照，否则一些新增数据很有可能尚未持久化），重启master，待master完全恢复后再开启slave的同步。

至于master为什么不开启rdb？性能不是主要原因，而是因为master开启rdb根本没有什么实际意义，其挂掉后最后写入的数据极大可能没有被dump，相比而言数据同步的速度一般会非常快，所以这部分数据一般会顺利地同步给slave，由slave完成dump，所以slave的rdb才是完整的。所以此方案只要能保证slave没问题，master几乎可以100%恢复数据。