这篇文章简略聊下redis里的RDB与AOF两种长久化。
RDB(redis database)长久化的特点，它能够手动执行也能够通过配置定期执行，手动执行的命令是SAVE与BGSAVE，其中SAVE会阻塞redis服务器过程，直到RDB文件创建实现，在创立过程中，服务器不解决其它命令；BGSAVE则会派生出一个出过程，由子过程创立RDB文件，服务器过程持续解决其它命令。如果是通过配置，那配置的办法是：
save 900 1save 300 10save 60 10000只有满足三个中的一个，BGSAVE就会执行：
- 服务器在900S之内，对数据库进行了至多1次批改。
- 服务器在300S之内，对数据库进行了至多10次批改。
- 服务器在60S之内，对数据库进行了至多10000次批改。
再说下RDB的文件保留的是所有的键值对数据，是通过压缩后的二进制文件，如果键值带有过期工夫，那么过期工夫也会被保存起来。
AOF(append only file)所存的内容是写命令，且是以纯文本模式保留。服务器在执行完一个写命令之后，会将这个写命令追加到aof_buf缓冲区开端。AOF能够通过配置appendfsync的值来管制将缓冲区写入和保留到AOF文件的频率，可配置的值有：always/everysec/no。
AOF数据不同步的问题
因为是将写命令先写到aof_buf缓存区而后距离一段时间后再写入到AOF文件里，如果在写入文件之前数据进行了批改，则会造成内存里的数据与AOF文件里的数据不统一。针对这个问题,redis会在后盾fork一个子过程进行AOF重写：学生成一个新的AOF文件，而后应用新生成的文件替换旧的AOF文件。
AOF文件多条反复命令问题
在AOF重写过程中，会去数据库里读取键现有的值(而不是去剖析已生成的旧的AOF文件)，如果能够应用一条命令进行记录则只记一条。比方：
redis> RPUSH list "a" "b"2redis> RPUSH list "c"3学生成的旧的AOF文件会别离对应两条命令，而重写的AOF通过剖析了当初数据库里存的数据后会将下面两条命令合成一条进行记录。
这里再对rdb与aof进行一下比照：
- rdb长处：体积小(存的是数据)、复原快、性能影响小(fork子过程)
- rdb毛病：数据失落可能性大(不能频繁执行)、影响cpu(fork工夫长后会有影响)
- aof长处：数据失落可能性小
- aof毛病：体积大(存的是命令)、性能影响大(先写aof再执行用户操作)、复原慢(须要解析命令)
抉择哪种须要依据业务场景来定：
- 对性能要求高、须要疾速复原倡议应用rdb
- 对数据完整性要求高，倡议应用aof
- 须要两者兼容，可应用二者混合(redis4.0后)