介绍
Redis
是内存型数据库,一旦主过程退出就会造成数据失落。它的长久化次要有两大机制,即 AOF
日志和 RDB
快照,本文次要关怀 AOF
日志。
过程
Redis
执行完一个写命令后,将写命令以协定文本的模式追加到 AOF
缓冲区开端,再通过 同步策略 来决定是否将 AOF
缓冲区中的内容写入 & 同步到 AOF
日志。
同步策略
AOF
机制提供了三个抉择,也就是配置项 appendfsync
的三个可选值:
- always:将
AOF
缓冲区中的所有内容 写入 并同步 到AOF
日志。 - everysec:将
AOF
缓冲区中的所有内容 写入 到AOF
日志,如果上次同步AOF
日志的工夫间隔当初超过 1 秒钟,那么对AOF
日志进行 同步。 - no:将
AOF
缓冲区中的所有内容 写入 到 AOF 日志,但并不对 AOF 日志进行 同步,何时同步由操作系统来决定。
三种策略的优缺点也不言而喻了,always
可靠性高性能低、no
可靠性低性能高,everysec
取两者折中。
重写机制
AOF
日志是以文件的模式记录接管到的所有写命令。随着接管的写命令越来越多,文件体积会越来越大。这也就意味着会带来一些问题。
- 操作系统对文件体积有限度,不能保留过大的文件。
- 对体积比拟大的文件进行追加写入,效率会升高。
AOF
日志体积过大,故障复原过程迟缓。
为了解决下面的问题,Redis
提供了重写性能。通过该性能,Redis
能够创立一份新的 AOF
日志来代替现有的 AOF
日志。
- 两份
AOF
日志所保留的数据库状态雷同。 - 新
AOF
日志不会蕴含节约空间的冗余命令。 - 新
AOF
日志体积小于等于原AOF
日志。
重写过程
为什么要放在子过程里执行?
不会造成主线程阻塞,子过程进行 AOF
重写期间,主线程能够持续解决命令申请。
重写过程中有写命令,会造成数据不统一吗?
不会,Redis
保护了 AOF
重写缓冲区,在主线程创立重写子过程后开始应用。如果重写期间有写命令申请,Redis
会追加写入 AOF
缓冲区和 AOF
重写缓冲区。当子过程实现创立新 AOF
日志后,主线程会将 AOF
重写缓冲区中的所有内容追加写入新 AOF
日志,此时新旧两份 AOF
日志所保留的数据库状态完全一致。最初,用新 AOF
日志笼罩旧 AOF
日志,实现 AOF
日志重写操作。