一，Redis持久化的两种方式

1，RDB，也加快照snapshots，它是按照规定时间内满足操作次数进行备份，把所有数据集合写到dump.rdb文件来实现持久化
来看看redis.conf中关于RDB的配置内容就清楚啦

# 900秒即15分钟内，至少1次更新，才进行备份
save 900 1
# 300秒即5分钟内，至少10次更新，才进行备份
save 300 10
# 60秒即15分钟内，至少1000次更新，才进行备份
save 60 10000

# dump备份的文件名
dbfilename dump.rdb
# dump备份文件的目录
dir /var/lib/redis/6379

2，AOF，即Append Only File，意思是只进行内容追加，它是将数据操作命令追加到指定的appendonly.aof文件
也来看看redis.conf中关于AOF的配置

# AOP开关，yes or on
appendonly yes
# 写入数据操作命令的文件
appendfilename "appendonly.aof"

# 每次数据操作之后，追加到指定文件
# 是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用
# appendfsync always
# 每秒强制执行，追加命令到指定文件
# 在性能和持久化方面做了很好的折中，是受推荐的方式
appendfsync everysec
# 根据操作系统，追加命令到指定文件
# 完全依赖OS的写入，性能最好但是持久化最没有保证，不被推荐
# appendfsync no

# 当进程中BGSAVE或BGREWRITEAOF命令正在执行时，Redis可能会阻塞一段时间
# 设置为yes，你可以阻止主进程中的fsync()调用，但是将会面临一定的数据丢失  
# 设置为no，即不管什么时候都进行appendfsync，可能会遇到Redis阻塞，DISK IO上冲突的情况
no-appendfsync-on-rewrite no   
# 当前的aof文件大小超过上次重写时的100%时，自动启动新的aof文件；
# 如果尚未重写过aof文件，那就取Redis启动时的aof文件大小值来做比较
auto-aof-rewrite-percentage 100 
# 重写aop文件的条件，当前aof文件大小必须到达这个最小值，避免文件太小而不断重写
auto-aof-rewrite-min-size 64mb 

二，两种方式分析

1，RDB
优点：
RDB类似定时备份整个数据库，比如每1小时进行一次更新dump.rdb；因为是备份了整个库，即使遇到灾难性问题，也可以恢复所有数据。
缺点：
每次重写dump.rdb文件，Redis都会fork出一个子进程来，而且占用内存和父进程一样，如果数量很大的话，这个备份过程将会很漫长，而且服务器消耗大；考虑到性能问题，RDB难以做到实时备份数据，所以存在短时间数据丢失的可能性，比如Redis突然宕机，5分钟内的新数据可能没有重写到dump.rdb中。

2，AOF
优点：
AOF可以采用每秒fsync的持久化模式，完整地记录了所有的数据操作记录，最多会丢失前一秒的数据；aof文件是原子性的，而且会自动重写
缺点：
因为记录了所有的数据操作记录而不只是最后一次操作，aof文件会比较大；在数据恢复方面也会比较慢，因为它的编码跟Redis内存数据编码不一样。

三，采用何种方式

1，如果能接受几分钟内的数据丢失，可以使用RDB；
2，如果数据实时性比较重要的话，还是使用AOF吧；

最终我选择的是：

1，其实，两种方式可以同时使用，所以不用纠结了，两种都配上吧，不过考虑到性能问题，你也可以选用其中一种，而且建议在slave上配置持久化，而不是master。

3，Redis 启动时， 如果 RDB 和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的