【中间件Redis】Redis四种持久化机制与选型参考

1.RDB（Redis DataBase,DB快照）

RDB是一种快照式的持久化方案，即将某一时刻的数据持久化到磁盘中。

• redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待所有数据都写入临时文件后，才会用该临时文件替换前次持久化的文件（默认的文件命名为dump.rdb）。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
• 在RDB方案中，redis会单独创建（fork）一个子进程来进行持久化操作，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
• 如果项目中对于数据的完整性不是那么敏感（丢失一部分缓存数据影响不大），可采用该机制。

2.AOF（Append Only File, 追加文件）

AOF机制分为两个阶段：

• 每次有新的写命令时AOF机制会将其追加到AOF文件（appendonly.aof）末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大.默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。
• 如果在追加日志时遇到磁盘空间满、inode满或断电等特殊情况导致日志写入不完整，也没有关系。redis提供了redis-check-aof工具，可以用来进行日志修复。
• 因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。
• 在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性。

默认机制

Redis默认使用的是RDB机制（即快照），通常项目对数据完整性的要求不是那么高的情况可以使用该机制。
redis.conf配置：

save 900 1 
save 300 10
save 60 10000

以上是默认配置：
900秒内，如果超过1个key被修改，则发起快照保存；
300秒内，如果超过10个key被修改，则发起快照保存 ；
60秒之内，如果1万个key被修改，则发起快照保存 ；

如不想使用上述默认机制，可通过修改配置文件中appendonly yes进行变更。

选型参考

1.如果想要获得可比于PostgreSql能提供给我们的数据安全程度，一般情况下我们应该结合使用RDB+AOF的机制；
2.如果关注数据安全，但是发生重大事故的情况下可以容忍几分钟的数据缺失，可以使用RDB机制；
3.有很多人在使用AOF机制，但是相比于RDB snapshot的数据库备份的个性化，快速重启特性并且in the event of bugs in the AOF engine , 不建议单独使用AOF。