共计 1111 个字符，预计需要花费 3 分钟才能阅读完成。
这篇文章简略聊下 redis 里的 RDB 与 AOF 两种长久化。
RDB(redis database)长久化的特点，它能够手动执行也能够通过配置定期执行，手动执行的命令是 SAVE 与 BGSAVE，其中 SAVE 会阻塞 redis 服务器过程，直到 RDB 文件创建实现，在创立过程中，服务器不解决其它命令；BGSAVE 则会派生出一个出过程，由子过程创立 RDB 文件，服务器过程持续解决其它命令。如果是通过配置，那配置的办法是：
save 900 1
save 300 10
save 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"
2
redis> RPUSH list "c"
3学生成的旧的 AOF 文件会别离对应两条命令，而重写的 AOF 通过剖析了当初数据库里存的数据后会将下面两条命令合成一条进行记录。
这里再对 rdb 与 aof 进行一下比照：
- rdb 长处：体积小(存的是数据)、复原快、性能影响小(fork 子过程)
- rdb 毛病：数据失落可能性大(不能频繁执行)、影响 cpu(fork 工夫长后会有影响)
- aof 长处：数据失落可能性小
- aof 毛病：体积大(存的是命令)、性能影响大(先写 aof 再执行用户操作)、复原慢(须要解析命令)
抉择哪种须要依据业务场景来定：
- 对性能要求高、须要疾速复原倡议应用 rdb
- 对数据完整性要求高，倡议应用 aof
- 须要两者兼容，可应用二者混合(redis4.0 后)
