REDIS AOF日志

AOF日志如何实现?

AOF(append only file)是写后日志,意思为Redis是先执行命令,把数据写入内存,然后才记录日志。
AOF中记录的是Redis收到的每一条命令,这些命令是以文本的形式保存下来。

“set testkey testvalue"命令后记录的日志为例,AOF内容为
*3
$3
set
$7
testkey
$9
testvalue

解释:其中*3表明有三部分,每部分由”$+数字"开头,后面紧跟具体的命令、键或值
“$3 set"表明这部分有3个字节,也就是"set"命令

AOF的好处

  1. AOF是写后日志,可以避免出现记录错误命令的情况(写后,表明现在系统已经执行命令成功了)
  2. 命令执行后才记录日志,不会阻塞当前的写操作
    在这里插入图片描述

AOF潜在风险

  1. 还没来的及写入日志就宕机了,这是无法用日志进行恢复(这里是使用redis当数据库,而不是作为mysql的缓存)
  2. AOF写会磁盘,会对下一个操作阻塞带来风险(AOF是在主线程中执行的,如果日志文件写入磁盘时,磁盘写压力大,就会导致写盘很慢,后续操作无法进行)

三种写回策略——写回磁盘

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

在这里插入图片描述
总结一下:想要获得高性能,就选择No策略;如果想要保证高可靠性保证,就选择Always策略;如果允许数据有一点丢失,又希望性能别受太大影响的话,那么就选择Everysec策略。

AOF文件过大带来的性能问题

  1. 文件系统本身对文件大小有限制,无法保存过大的文件
  2. 如果文件太大,之后再往里面追加命令记录的话,效率也会变低
  3. 如果发生宕机,AOF中记录的命令要被一个个重新执行,用于故障恢复,如果文件过大,会导致恢复过慢,影响redis的正常使用

采用AOF重写来解决AOF过大带来的问题

AOF重写

  • 多条命令变为一条(旧日志文件中的多条命令,在重写后的新日志中变成了一条命令)
  • 在重写的时候,是根据这个键值对当前的最新状态,为它生成对应的写入命令。(具体看图片)
    在这里插入图片描述
    进一步思考

AOF重写会阻塞吗

重写过程是由后台线程bgrewriteaof来完成的,这也是为了避免阻塞主线程,导致数据库性能下降
  • ”一个拷贝“
  • 每次执行重写时,主线程fork()出后台到的bgrewriteaof子进程。此时,fork会把主线程的内存拷贝一份给bgrewriteaof子进程
  • ”两处日志“
  • 因为主线程未阻塞,仍然可以处理新来的操作。第一处日志就是指正在使用的AOF日志,Redis会把这个操作写到他的缓冲区。这样一来,即使宕机了,这个AOF日志的操作仍然是齐全的,可以用于恢复
  • 第二处日志,就是指的新的AOF重写日志。这个操作也会被写到AOF重写缓冲,这样重写日志才不会丢失最新的操作。完成之后就可以用新的AOF来替代旧的AOF了。
  • 在这里插入图片描述
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值