[redis进阶一]redis的持久化(2)AOF篇章

目录

一 为什么有了RDB持久化机制还要有AOF呢

板书介绍具体原因:

​编辑二 详细讲解AOF机制

(1)AOF的基本使用

 1)板书如下

2)开启AOF机制:

3) AOF工作流程

(2)AOF是否会影响到redis性能

​编辑

(3)AOF缓冲区刷新策略

(4)AOF的重写机制

板书如下:

为什么要有这个重写机制???

重写流程 :

(5)混合持久化

板书如下

启动时数据恢复

(6)对于信号的解释

四  本章重点回顾


一 为什么有了RDB持久化机制还要有AOF呢

原因:那肯定是RDB机制有无法满足需求的场景,肯定是RDB有缺点,所以才又引入了AOF机制

板书介绍具体原因:

二 详细讲解AOF机制

(1)AOF的基本使用

AOF(AppendOnlyFile)持久化:以独⽴⽇志的⽅式记录每次写命令,重启时再重新执⾏AOF ⽂件中的命令达到恢复数据的⽬的。AOF的主要作⽤是解决了数据持久化的实时性,⽬前已经是 Redis 持久化的主流⽅式。理解掌握好AOF持久化机制对我们兼顾数据安全性和性能⾮常有帮助。

 1)板书如下

2)开启AOF机制:

开启AOF功能需要设置配置:appendonlyyes,默认不开启为no。AOF⽂件名通过 appendfilename 配置(默认是appendonly.aof)设置。保存⽬录同RDB持久化⽅式⼀致,通过dir 配置指定。AOF的⼯作流程操作:命令写⼊(append)、⽂件同步(sync)、⽂件重写 (rewrite)、重启加载(load),如图所⽰。

步骤一通过root用户使用vim打开以下文件:

ls /etc/redis/redis.conf

找到appendonly选项,默认为no

步骤二:修改 "appendonly"选项为yes并保存

3) AOF工作流程

  1. 所有的写⼊命令会追加到aof_buf(缓冲区)中。
  2. AOF缓冲区根据对应的策略向硬盘做同步操作。
  3. 随着硬盘AOF⽂件越来越⼤,需要定期对AOF⽂件进⾏重写,达到压缩的⽬的。
  4. 当Redis服务器启动时,可以加载AOF⽂件进⾏数据恢复。

命令写入:

AOF命令写⼊的内容直接是⽂本协议格式。例如sethelloworld这条命令,在AOF缓冲区会追加如下 ⽂本:

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

此处遵守Redis格式协议,Redis选择⽂本协议可能的原因:⽂本协议具备较好的兼容性;实现简单; 具备可读性。

AOF过程中为什么需要aof_buf这个缓冲区?Redis使⽤单线程响应命令,如果每次写AOF⽂件都直 接同步硬盘,性能从内存的读写变成IO读写,必然会下降。先写⼊缓冲区可以有效减少IO次数,同 时,Redis还可以提供多种缓冲区同步策略,让⽤⼾根据⾃⼰的需求做出合理的平衡。 

(2)AOF是否会影响到redis性能

讲解都在下边板书中

(3)AOF缓冲区刷新策略

板书如下:

⽂件同步:

Redis 提供了多种AOF缓冲区同步⽂件策略,由参数appendfsync控制,不同值的含义如表所⽰。

系统调⽤write和fsync说明:

• write操作会触发延迟写(delayedwrite)机制。Linux在内核提供⻚缓冲区⽤来提供硬盘IO性 能。write操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制,例如:缓冲区 ⻚空间写满或达到特定时间周期。同步⽂件之前,如果此时系统故障宕机,缓冲区内数据将丢失。

• Fsync针对单个⽂件操作,做强制硬盘同步,fsync将阻塞直到数据写⼊到硬盘。

• 配置为always时,每次写⼊都要同步AOF⽂件,性能很差,在⼀般的SATA硬盘上,只能⽀持⼤ 约⼏百TPS写⼊。除⾮是⾮常重要的数据,否则不建议配置。

• 配置为no时,由于操作系统同步策略不可控,虽然提⾼了性能,但数据丢失⻛险⼤增,除⾮数据 重要程度很低,⼀般不建议配置。

• 配置为everysec,是默认配置,也是推荐配置,兼顾了数据安全性和性能。理论上最多丢失1秒的 数据。 

(4)AOF的重写机制

板书如下:

总结重写机制:就比如你要算你的利润,这个月挣了6000杂七杂八花去2000,最后净利润4000,下个月在计算总利润的时候直接从这4000开始算,第一个月中干活挣了100买水花20又写文案挣了50买水果花60等等中间状态直接舍去,只看最后的状态

为什么要有这个重写机制???

答案:随着命令不断写⼊AOF,⽂件会越来越⼤,

为了解决这个问题,Redis引⼊AOF重写机制压缩⽂件体积。AOF⽂件重写是把Redis进程内的数据转化为写命令同步到新的AOF⽂件。 重写后的AOF为什么可以变⼩?有如下原因:

  1. 进程内已超时的数据不再写⼊⽂件。
  2. 旧的AOF中的⽆效命令,例如del、hdel、srem等重写后将会删除,只需要保留数据的最终版本。
  3. 多条写操作合并为⼀条,例如lpush list a、lpush list b、lpush list c可以合并为lpushlist a b c。

较⼩的AOF⽂件⼀⽅⾯降低了硬盘空间占⽤,⼀⽅⾯可以提升启动Redis时数据恢复的速度。

AOF重写过程可以⼿动触发和⾃动触发:

  • ⼿动触发:调⽤bgrewriteaof命令。
  • ⾃动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定⾃动触发时 机。
    • auto-aof-rewrite-min-size:表⽰触发重写时AOF的最⼩⽂件⼤⼩,默认为64MB。
    • auto-aof-rewrite-percentage:代表当前AOF占⽤⼤⼩相⽐较上次重写时增加的⽐例。

重写流程 :

板书如下

1)执⾏AOF重写请求。如果当前进程正在执⾏AOF重写,请求不执⾏。如果当前进程正在执⾏bgsave操作,重写命令 延迟到bgsave完成之后再执⾏。

2)⽗进程执⾏fork创建⼦进程。

3)重写:

        a.主进程fork之后,继续响应其他命令。所有修改操作写⼊AOF缓冲区并根据appendfsync策 略同步到硬盘,保证旧AOF⽂件机制正确。

        b.⼦进程只有fork之前的所有内存信息,⽗进程中需要将fork之后这段时间的修改操作写⼊ AOF重写缓冲区中。

4)⼦进程根据内存快照,将命令合并到新的AOF⽂件中。

5)⼦进程完成重写

        a.新⽂件写⼊后,⼦进程发送信号给⽗进程。

        b.⽗进程把AOF重写缓冲区内临时保存的命令追加到新AOF⽂件中。

        c.⽤新AOF⽂件替换⽼AOF⽂件。

(5)混合持久化

板书如下

启动时数据恢复

当Redis启动时,会根据RDB和AOF⽂件的内容,进⾏数据恢复,如图所⽰。

 

(6)对于信号的解释

直接看板书讲解:

四  本章重点回顾

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我叫珂蛋儿吖

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值