简单谈谈Redis 持久化机制

Redis是我们常用的key-value数据库，并且Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。Redis有两种持久化机制：RDB(Redis DataBase)和AOF(Append-Only File)。

1、RDB(Redis DataBase)

RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。 快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。

优点

1、只会产生一个文件dump.rdb，方便持久化；
2、容灾性好，一个文件可以保存到安全的磁盘；
3、fork子进程来完成写操作，让主进程继续处理命令，能够达到IO最大化；
4、使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
4、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点

1、由于RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失，数据安全性低，所以RDB比较适合在数据要求不是特别严格的时候使用。
2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

2、AOF(Append-Only File)

AOF：AOF能够弥补RDB数据不一致性的缺点。AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，文件中可以看到详细的操作记录。Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

AOF过程
当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复

优点

1、AOF的数据安全性更高，因为在AOF持久化中可以配置appendfsync属性，其中always，每进行一次命令操作就记录到AOF文件中一次。
注意：appendfysnc是对redis性能有重要影响的参数之一。可取三种值：always、everysec和no。
设置为always时，会极大消弱Redis的性能，因为这种模式下每次write后都会调用fsync（Linux为调用fdatasync）。
设置为no，则write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的。
everysec为最多每秒调用一次fsync，这种模式性能并不是很糟糕，一般也不会产生毛刺，这归功于Redis引入了BIO线程，所有fsync操作都异步交给了BIO线程。
2、通过append模式写文件，即使服务器突然出现故障，也可以通过redis-check-aof工具解决数据一致性问题。
3、AOF文件没被rewrite之前，可以删除其中的某些命令，比如误操作的flushall。

缺点

1、AOF文件比RDB文件大，且恢复速度慢；数据集大的时候，比rdb启动效率低。
2、根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

使用场景

根据上述的分析Redis的两种持久化机制，各有各的优缺点，所以并不能说哪一种机制性能比较好，需要根据自己的使用场景来选择：
1、如果对于数据要求不是特别严格，则可以使用RDB模式，因为它可以让你更快地重启redis，进行数据恢复。
2、如果对于数据的一致性要求比较高，而对于数据恢复的速度没有要求，则可以使用AOF模式。
3、Redis官方文档推荐同时配置RDB和AOF两种模式，以AOF为主，RDB为辅，AOF记录日志，RDB做数据库备份，以及AOF引擎失效后的替代。

参考：Redis官网

微信公众号