Redis持久化

1.RDB：在指定的时间间隔能对你的数据进行快照存储。禁用RDB配置：在save的最后一行写上：save “”

时间策略

save 900 1
save 300 10
save 60 10000

文件名称

dbfilename dump.rdb

文件保存路径

dir /home/work/app/redis/data/

如果持久化出错，主进程是否停止写入

stop-writes-on-bgsave-error yes

是否压缩

rdbcompression yes

导入时是否检查

rdbchecksum yes

2.AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

是否开启aof

appendonly yes

文件名称

appendfilename “appendonly.aof”

同步方式

appendfsync everysec

aof重写期间是否同步

no-appendfsync-on-rewrite no

重写触发配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

加载aof时如果有错如何处理

aof-load-truncated yes

文件重写策略

aof-rewrite-incremental-fsync yes

优缺点对比：

优点：

RDB 方式可以保存过去一段时间内的数据，并且保存结果是一个单一的文件，可以将文件备份到其他服务器，并且在回复大量数据的时候，RDB 方式的速度会比 AOF 方式的回复速度要快。

AOF 方式默认每秒钟备份1次，频率很高，它的操作方式是以追加的方式记录日志而不是数据，并且它的重写过程是按顺序进行追加，所以它的文件内容非常容易读懂。可以在某些需要的时候打开 AOF 文件对其编辑，增加或删除某些记录，最后再执行恢复操作。
缺点：

RDB 由于备份频率不高，所以在回复数据的时候有可能丢失一小段时间的数据，而且在数据集比较大的时候有可能对毫秒级的请求产生影响。

AOF 的文件提及比较大，而且由于保存频率很高，所以整体的速度会比 RDB 慢一些，但是性能依旧很高。
推荐：

分析对比两种方式并做了测试后，发现这是两种不同风格的持久化方式，那么应该如何选择呢？

对于企业级的中大型应用，如果不想牺牲数据完整性但是又希望保持高效率，那么你应该同时使用 RDB 和 AOF 两种方式；
如果你不打算耗费精力在这个地方，只需要保证数据完整性，那么优先考虑使用 AOF 方式；
RDB 方式非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择。