Redis持久化之AOF日志

一、Redis为什么要实现持久化

我们知道使用Redis,读写数据的速度都很快是因为数据存储在内存中,但是正是因为数据存储在内存中,所以我们无可避免要面对一个问题:一旦服务器宕机,内存中的数据将会全部丢失。

二、Redis如何实现数据的持久化——AOF日志

当我们把Redis用作缓存的时候,服务器宕机了,我们还可以从后端数据库恢复数据,但是当我们把Redis直接用作数据库的时候,我们就没办法通过后端数据库恢复了,所以此时我们就需要通过另外的方式来实现数据的持久化。

1、如何用AOF日志实现数据持久化?

AOF日志是“写后”日志,意思即是Redis先执行了命令,把数据写入了内存了,再把命令记录到日志。(AOF 里记录的是 Redis 收到的每一条命令,这些命令是以文本形式保存的)

为什么AOF是“写后”日志而不是“写前”?
  1. 因为避免额外的检查开销,Redis 在向 AOF 里面记录日志的时候,并不会先去对这些命令进行语法检查。所以,如果先记日志再执行命令的话,日志中就有可能记录了错误的命令,Redis 在使用日志恢复数据时,就可能会出错。所以采取写后日志这种方式,就是先让系统执行命令,只有命令能执行成功,才会被记录到日志中
  2. 而且在命令执行后才记录日志,不会阻塞当前的写操作。
2、AOF的潜在风险
  • 数据丢失:AOF也存在一些风险,其中当我们执行完命令,还没来得及把日志写到磁盘就宕机了,数据将会有丢失的风险。
  • 后续操作阻塞:AOF虽然避免了对当前命令的阻塞,但因为AOF日志写入磁盘的操作也是在主线程执行的,如果磁盘写入的压力很大就会导致写盘慢,从而导致后续的操作会被堵塞

这两个风险都是和 AOF 写回磁盘的时机相关的,所以我们得学会控制一个写命令执行完后 AOF 日志写回磁盘的时机,这就和我们的写回策略有关了。

3、三种写回策略

我们可以AOF 配置项appendfsync设置不同的值控制日志写回磁盘的时机。

  • Always(同步写回):每个写命令执行完,立马同步地将日志写回磁盘;
  • Everysec(每秒写回):每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘;
  • No(操作系统控制的写回):每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。

根据上面三种可想策略,其实我们细想一下就知道解决数据丢失问题和阻塞问题无法做到两全其美,我们只能根据业务场景在性能和可靠性保证之间做取舍。

4、AOF日志文件太大会有什么影响?

因为AOF是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多,AOF 文件会越来越大则会带来以下问题:

  1. 文件系统本身对文件大小有限制,无法保存过大的文件;
  2. 文件过大,再往里面追加命令记录的话,效率也会变低;
  3. 如果发生宕机,AOF 中记录的命令需要被要一个个被重新执行,用于故障恢复。此时日志文件太大,整个恢复过程就会非常缓慢,这就会影响到 Redis 的正常使用。
(1)怎么解决AOF日志太大?(AOF 重写机制

AOF 重写机制:AOF 重写机制就是在重写时,Redis 根据数据库的现状创建一个新的 AOF 文件,也就是说,读取数据库中的所有键值对,然后对每一个键值对用一条命令记录它的写入。例如我们对键testkey已经修改了几次了,最后在数据库的最新值是testvalue。重写机制直接用一条set testkey testvalue的命令代替了前面的几条修改命令,大大节省了空间。

(2)重写是否会阻塞主线程?

通过重写机制节省了很多空间,但是重写这个过程是否会阻塞主线程呢?

答:不会的。重写过程是由主线程fork出的后台子进程 bgrewriteaof 来完成的,fork 会把主线程的内存拷贝一份给
bgrewriteaof 子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof
子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。

(3)重写时如果主线程有新来的操作怎么办?

答:如果有新来操作,新旧的AOF日志都有写入。

因为主线程未阻塞,仍然可以处理新来的操作。此时,如果有写操作,Redis 会首先把这个操作写到它正在使用的 AOF
日志的缓冲区。这样一来,即使宕机了,这个 AOF
日志的操作仍然是齐全的,可以用于恢复。而且这个操作也会被写到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的
AOF 文件,以保证数据库最新状态的记录。此时,我们就可以用新的 AOF 文件替代旧文件了。

5、总结
  • AOF 日志的三种写回策略,分别是 Always、Everysec 和 No,这三种策略在可靠性上是从高到低,而在性能上则是从低到高。
  • 为了避免日志文件过大,Redis 还提供了 AOF 重写机制,直接根据数据库里数据的最新状态,生成这些数据的插入命令,作为新日志。这个过程通过后台线程完成,避免了对主线程的阻塞。

本文为自己的阅读总结,更多详细内容参考原文:Redis核心技术与实战

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值