此篇是copy 小林coding的Redis持久化篇,感谢小林coding的详细讲解和图解
AOF(append only file)
保存写操作命令到日志的持久化方式,就是 Redis 里的 AOF(*Append Only File*) 持久化功能,注意只会记录写操作命令,读操作命令是不会被记录的
先执行操作后写入AOF日志好处
- 避免额外的检查开销,因为如果先将写操作命令记录到 AOF 日志里,再执行该命令的话,如果当前的命令语法有问题,那么如果不进行命令语法检查,该错误的命令记录到 AOF 日志里后,Redis 在使用日志恢复数据时,就可能会出错。
- 不会阻塞写操作命令,如果先写文件而文件IO太久,会导致阻塞
先执行操作后写入AOF日志风险
- 如果还未写入硬盘就宕机,会丢失部分数据
- 写文件可以是同步写入的,有可能会阻塞下一条命令执行
3种写会回策略
redis追加AOF的步骤
-
Redis 执行完写操作命令后,会将命令追加到
server.aof_buf
缓冲区; -
然后通过
write()
系统调用,将 aof_buf 缓冲区的数据写入到 AOF 文件,此时数据并没有写入到硬盘,而是拷贝到了内核缓冲区 page cache,等待内核将数据写入硬盘; -
具体内核缓冲区的数据什么时候写入到硬盘,由内核决定
Redis 提供了 3 种写回硬盘的策略,控制的就是上面说的第三步的过程。
在 redis.conf
配置文件中的 appendfsync
配置项可以有以下 3 种参数可填:
- Always:总是执行完命令后,内核缓冲区的数据马上写入硬盘
- 好处:可以最大程度保证数据不丢失
- 坏处:每次都会触发IO,导致进程阻
- No:由操作系统控制何时从内核缓冲区中写入硬盘
- 好处:文件IO减少
- 坏处:内核写入时间不可控,有可能导致数据大量丢失
- Everysec:每秒执行一次写入
- 好处:曲中
- 坏处:丢失一秒的数据
如果想要应用程序向文件写入数据后,能立马将数据同步到硬盘,就可以调用 fsync()
函数,这样内核就会将内核缓冲区的数据直接写入到硬盘,等到硬盘写操作完成后,该函数才会返回。
- Always 策略就是每次写入 AOF 文件数据后,就执行 fsync() 函数;
- Everysec 策略就会创建一个异步任务来执行 fsync() 函数;
- No 策略就是永不执行 fsync() 函数
AOF重写机制
AOF 日志是一个文件,随着执行的写操作命令越来越多,文件的大小会越来越大。
所以,Redis 为了避免 AOF 文件越写越大,提供了 AOF 重写机制,当 AOF 文件的大小超过所设定的阈值后,Redis 就会启用 AOF 重写机制,来压缩 AOF 文件。
AOF 重写机制:是在重写时,读取当前数据库中的所有键值对,然后将每一个键值对用一条命令记录到「新的 AOF 文件」,等到全部记录完后,就将新的 AOF 文件替换掉现有的 AOF 文件。
AOF后台重写
写入 AOF 日志的操作虽然是在主进程完成的,因为它写入的内容不多,所以一般不太影响命令的操作。
但是在触发 AOF 重写时,比如当 AOF 文件大于 64M 时,就会对 AOF 文件进行重写,这时是需要读取所有缓存的键值对数据,并为每个键值对生成一条命令,然后将其写入到新的 AOF 文件,重写完后,就把现在的 AOF 文件替换掉。
后台重写的好处
- 子进程不阻塞主进程
- 拥有创建子进程前主进程的数据拷贝。这里使用子进程而不是线程,因为如果是使用线程,多线程之间会共享内存,那么在修改共享内存数据的时候,需要通过加锁来保证数据的安全,而这样就会降低性能。
RDB快照
RDB 快照就是记录某一个瞬间的内存数据,记录的是实际数据,而 AOF 文件记录的是命令操作的日志,而不是实际的数据。
因此在 Redis 恢复数据时, RDB 恢复数据的效率会比 AOF 高些,因为直接将 RDB 文件读入内存就可以,不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。
RDB 的 save和bgsave
- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和执行操作命令在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和执行操作命令在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
# redis.conf
save 900 1
save 300 10
save 60 10000
实际上执行的是 bgsave 命令,也就是会创建子进程来生成 RDB 快照文件。
只要满足上面条件的任意一个,就会执行 bgsave,它们的意思分别是:
- 900 秒之内,对数据库进行了至少 1 次修改;
- 300 秒之内,对数据库进行了至少 10 次修改;
- 60 秒之内,对数据库进行了至少 10000 次修改。
这里提一点,Redis 的快照是全量快照,也就是说每次执行快照,都是把内存中的「所有数据」都记录到磁盘中。
所以可以认为,执行快照是一个比较重的操作,如果频率太频繁,可能会对 Redis 性能产生影响。如果频率太低,服务器故障时,丢失的数据会更多。
通常可能设置至少 5 分钟才保存一次快照,这时如果 Redis 出现宕机等情况,则意味着最多可能丢失 5 分钟数据。