中国有哪些企业网站,灰色行业seo,如何制作网站教程视频讲解,怎样建设自己的视频网站文章目录 AOF概念如何使用AOFAOF工作流程命令写入演示文件同步策略 AOF的重写机制概念触发重写机制AOF重写流程 启动时数据恢复混合持久化总结 AOF
概念
AOF持久化:以独立日志的方式记录每次的写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的.AOF的主要作用是解决… 文章目录 AOF概念如何使用AOFAOF工作流程命令写入演示文件同步策略 AOF的重写机制概念触发重写机制AOF重写流程 启动时数据恢复混合持久化总结 AOF
概念
AOF持久化:以独立日志的方式记录每次的写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的.AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式.
如何使用AOF
开启AOF功能需要修改配置文件:appendonly yes,默认情况下不开启.AOF文件名通过appendfilename配置(默认是appendonly.aof)设置.保存目录同时RDB持久化方式一致,通过dir配置指定.(注意:当开启AOF的时候,RDB一般就不会生效了) 打开配置文件vim /etc/redis/redis.conf,将该位置修改为appendonly yes 可修改AOF文件名: 保存目录:
AOF工作流程 所有的写入命令会追加到aof_buf缓冲区中AOF缓冲区根据对应的策略向硬盘做同步操作随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩目的 重写:在最终结果一致的情况下,可以剔除命令中一些比较冗余的操作 当Redis服务器启动实词,可以加载AOF文件进行数据恢复
命令写入演示
我们在配置文件中打开AOF持久化后,当我们输入命令时,在var/lib/redis目录中自动出现了一个新的目录:appendonlydir 打开appendonlydir目录
-rw-r--r-- 1 root root 88 Oct 6 20:39 appendonly.aof.1.base.rdb
-rw-r--r-- 1 root root 73 Oct 6 20:39 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root 88 Oct 6 20:39 appendonly.aof.manifestappendonly.aof.1.base.rdb这是 Redis AOF 文件的基础 RDBRedis Database Backup文件通常用于在 AOF 恢复时提供一个初始的数据库状态。 appendonly.aof.1.incr.aof这是增量 AOF 文件包含自上次 RDB 快照以来对数据库的所有写操作。它是 AOF 的核心部分。 appendonly.aof.manifest这是 AOF 文件的清单包含有关 AOF 文件的元数据如版本、文件大小等。
注意:AOF命令写入的内容直接是文本协议格式.例如:set key111 11111111111111111; 这条命令,在AOF文件中会追加如下文本: 疑问1:AOF作为一种实时备份的持久化方式,是否会影响Redis的性能呢? 答案: 不会 原因:
AOF会先写入内存缓冲区aof_buf中,然后一次性刷入磁盘中,这样可以减少磁盘IOAOF在磁盘中时顺序读写,新的命令会追加到原本的文件中 疑问2:AOF过程中为什么需要aof_buf这个缓冲区? Redis使用单线程响应命令,如果每次写AOF文件都直接同步到硬盘中,性能就会从内存的读写变成IO读写,性能必然下降.所以,先写入缓冲区中可以有效减少IO次数,同时,Redis还可以提供多种缓冲区同步策略,让用户根据自己的需求做出合理的平衡.
文件同步策略
Redis提供了多种AOF缓冲区同步文件策略,由参数appendfsync来控制. 在配置文件中:
可配置值说明always命令写入aof_buf后调用fsync同步,完成后返回everysec(默认设置)命令写入aof_buf后只执行write操作,不进行fsync.每秒由同步线程进行fsyncno命令写入aof_buf后只执行write操作,由OS控制fsync的频率
上述的同步文件策略,数据写入磁盘的频率由高到低,性能由低到高
系统调用write和fsync说明:
write会触发延迟写机制.Linux在内核提供页缓冲区用来提升硬盘IO性能.write操作在写入系统缓冲区后立即返回.同步硬盘操作依赖于系统调度控制,例如:缓冲区页空间写满或者达到了特定的时间周期.同步文件之前,如果此时系统故障宕机,缓冲区内数据将会丢失.(即 将内存中的数据先写入到内核的页缓冲区中,再由系统调度控制同步硬盘操作)Fsync针对单个文件操作,做强制硬盘同步,fsync将阻塞直到数据写入到硬盘 配置always时,每次写入都要同步AOF文件,性能很差,在一般的SATA硬盘上,只能支持大约几百TPS写入.除非是非常重要的数据,否则不建议配置.配置为no时,由于操作系统同步策略不可控,虽然提高了性能,但是数据丢失风险大增,除非数据的重要程度很低,否则不建议配置配置为svseysec,是默认配置,也是推荐配置,兼顾了数据安全性和性能.理论上最多丢失1秒的数据
AOF的重写机制
概念
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入了AOF重写机制用来压缩文件的体积.AOF文件重写是把Redis进程内的数据转化为写命令同步到新的AOF文件中 重写后的AOF文件体积为什么可以变小:
进程内已经超时的数据不再写入到文件中旧的AOF中的无效命令,例如del,hdel,srem等重写后将会删除,只需要保留数据的最终版本多条写操作合并为一条,例如:lpush list a,lpush list b,lpush list c可以合并为lpush list a b c.
较小的AOF文件一方面降低了硬盘空间的占用,一方面可以提升启动Redis时数据恢复的速度
触发重写机制
触发重写机制分为:手动触发和自动触发
手动触发:调用bgrewriteaof命令自动触发:根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发的时机(在配置文件中可自行配置) auto-aof-rewrite-min-size:表示触发重写时AOF的最小文件大小,默认为64MBauto-aof-rewrite-percentage:代表当前AOF占用大小相比较上次重写时增加的比例
AOF重写流程 执行AOF重写请求:如果当前进程正在执行AOF重写,请求不执行.如果当前进程正在执行bgsave操作,冲写命令延迟到bgsave执行结束之后再执行父进程执行fork创建子进程重写:不关心原来的AOF文件的状态,子进程只需要把内存中当前的数据获取出来,再以AOF的格式写入到一个新的AOF文件中 主进程fork之后,继续响应其他命令.所有修改操作写入AOF缓冲区之后再根据appendfsync策略同步到硬盘中,保证旧AOF文件机制正确子进程只有fork之前的所有内存信息,父进程中需要将fork之后这段时间的修改操作写入到AOF重写缓冲区中 子进程根据内存快照,将命令合并到新的AOF文件中去子进程完成重写 新文件写入后,子进程发送信号给父进程父进程把AOF重写缓冲区内临时保存的命令追加到新的AOF文件中用新AOF文件替换老的AOF文件
启动时数据恢复
当Redis启动时,会根据RDB和AOF文件的内容,进行数据恢复 根据持久化文件进行数据恢复
混合持久化
混合持久化结合了RDB和AOF的特点,按照aof的方式,每一个请求/操作,都记录写入aof-use-rdb-preamble文件中,在触发aof重写之后,就会把当前的内存状态按照rdb的二进制格式写入到新的AOF文件中,后续在进行操作,仍然是按照aof的文本格式追加到文件后面
总结
Redis提供了两种持久化的方案:RDB和AOFRDB视为内存快照,产生的内容更为紧凑,占用空间小,恢复速度更快.但是产生RDB的开销较大,不适合进行实时持久化,一般用于冷备和主从复制AOF视为对修改命令保存,在恢复时需要重放命令.并且有重写机制来定期压缩AOF文件RDB和AOF都是用fork来创建子进程,利用Linux子进程拥有父进程内存快照的特点来进行持久化,尽可能不影响主进程继续处理后续命令.
