去韩国用什么地图导航,seo网站推广策略,电脑页游排行榜前十名,生活类网站内容建设1 : AOF 是什么 以日志的形式来记录每个写操作#xff08;增量保存#xff09;#xff0c;将redis执行过的所有写指令记录下来#xff08;读操作不记 录#xff09;#xff0c;只允追加文件但不可改写文件#xff0c;redis启动之初会读取该文件重新构造数据#xff0c;…1 : AOF 是什么 以日志的形式来记录每个写操作增量保存将redis执行过的所有写指令记录下来读操作不记 录只允追加文件但不可改写文件redis启动之初会读取该文件重新构造数据换言之redis重启 的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 2 : AOF持久化流程 1. 客户端的请求写命令会被append追加到AOF缓冲区内 2. AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中 3. AOF文件大小超过重写策略或手动重写时会对AOF文件进行重写rewrite压缩AOF文件容量 4. redis服务器重启时会重新load加载AOF文件中的写操作达到数据恢复的目的 3 : AOF默认不开启
可以在 redis.conf 文件中对AOF进行配置 1. appendonly no # 是否开启AOFyes开启no不开启默认为no 2. appendfilename “appendonly.aof” # aof文件名称默认为appendonly.aof 3. dir ./ # aof文件所在目录默认./表示执行启动命令时所在的目录比如我们在/opt目录中去执行 4. redis-server /etc/redis.conf 来启动redis那么dir此时就是/opt目录 4 : 、AOF和RDB同时开启redis听谁的
AOF和RDB同时开启系统默认取AOF的数据数据不会存在丢失
5 : AOF启动/修复/恢复 AOF的备份机制和性能虽然和RDB不同但是备份和恢复的操作同RDB一样都是拷贝备份文件 需要恢复时再拷贝到Redis工作目录下启动系统即加载 正常恢复 1. 修改默认的appendonly no改为yes 2. 将有数据的aof文件复制一份保存到对应的目录查看目录config get dir 3. 恢复重启redis然后重新加载 异常恢复 1. 修改默认的appendonly no改为yes 2. 如遇到aof文件损坏通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行 恢复 6 : AOF同步频率设置 可以在redis.config中配置AOF同步的频率 appendfsync always每次写入立即同步 始终同步每次redis的写入都会立刻记入日志性能较差但数据完整性比较好。 appendfsync everysec每秒同步 每秒同步每秒记录日志一次如果宕机本秒数据可能丢失更新的命令会放在内存中AOF缓冲区每秒将缓冲区的命令追加到AOF文件 appendfsync no不主动同步 redis不主动进行同步把同步交给操作系统。 7 : rewrite压缩AOF文件压缩
7.1rewrite压缩是什么 AOF采用文件追加方式文件会越来越大为了避免出现此情况新增了重写机制当AOF文件的大小 超过锁审定的阈值时Redis就会启动AOF文件的内容压缩只保留可以恢复数据的最小指令集可以使 用命令bgrewriteaof触发重写。 7.2重写原理如何实现重写 AOF文件持续增长而过大时会fork出一条新进程来将文件重写也是先写临时文件最后在rename替 换旧文件redis4.0版本后的重写是指就把rdb的快照以二进制的形式附在新的aof头部作为已 有的历史数据替换掉原来的流水账操作。 7.3触发机制何时重写
bgrewriteaof手动触发重写 从 Redis 2.4 开始 AOF 重写由 Redis 自行触发 bgrewriteaof 仅仅用于手动触发重写操作。 redis会记录上次重写的aof大小默认配置是当aof文件大小是上次rewrite后大小的2倍且文件大于64M 时触发。 重写虽然可以节约大量磁盘空间减少恢复时间但是每次重写还是有一定负担的因此设置redis满足 一定条件才会进行重新。 7.4 auto-aof-rewrite-percentage设置重写基准值 设置重写的基准值默认100当文件达到100%时开始重写文件是原来重写后文件的2倍时重写。 7.5 auto-aof-rewrite-min-size设置重写基准值 设置重写的基准值默认64MBAOF文件大小超过这个值开始重写。 举个例子 文件达到70MB开始重写降到50MB下次什么时候开始重写100MB 系统载入时或者上次重写完毕时redis会记录此时AOF大小设置base_size。 如果Redis的AOF当前大小base_sizebase_size*100%( auto-aof-rewrite-percentage 默认值) 且 当 前大小64mb( auto-aof-rewrite-min-size 默认值)的情况下redis会对AOF进行重写 8 重写流程
127.0.0.1:6379 bgrewriteaof
Background append only file rewriting started手动执行 bgrewriteaof 命令触发重写判断是否当前有bgfsave或bgrewriteaof在运行如果有则等待该命令结束后再继续执行主进程fork出子进程执行重写操作保证主进程不会阻塞子进程遍历redis内存中的数据到临时文件客户端的写请求同时写入aof_buf缓冲区和 aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失子进程写完新的AOF文件后向主进程发送信号父进程更新统计信息主进程把aof_rewrite_buf中的数据写入到新的AOF文件使用新的AOF文件覆盖旧的AOF文件完成AOF重写 no-appendfsync-on-rewrite重写时不会执行appendfsync操作 该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘也就是说在进 行AOF重写的时候如果此时有写操作进俩此时写操作的命令会放在aof_buf缓存中内存中而不 会将其追加到旧的AOF文件中这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压 力。 默认是ON表示关闭即在AOF重写时会对AOF缓冲区中的数据做同步磁盘操作这在很大程度上保 证了数据的安全性。 但在数据量很大的场景因为两者都会消耗磁盘IO对磁盘的影响较大可以将其设置为“yes”减轻磁盘 压力但在极端情况下可能丢失整个AOF重写期间的数据。 如果no-appendfsync-on-rewrite为yes不写入aof文件只写入缓存用户请求不会阻塞但是在这 段时间如果宕机会丢失这段时间的缓存数据。降低数据安全性提高性能 如果no-appendfsync-on-rewrite为no还是会把数据库往磁盘里刷但是遇到重写操作可能会发生 阻塞。数据安全但是性能降低 9 : AOF优势
备份机制更稳健丢失数据概率更低可读的日志文本通过操作AOF文件可以处理误操作
10 : 劣势
比RDB占用更多的磁盘空间恢复备份速度要慢每次读写都同步的话有一定的性能压力存在个别bug造成不能恢复
小总结 : 1. AOF文件是一个只进行追加的日志文件 2. edis可以在AOF文件体积变得过大时自动地在后台对AOF文件进行重写 3. AOF文件有序地保存了对数据库执行的所有写入操作这些写入操作以redis协议的格式保存因此 AOF文件的内容非常容易被人读懂对文件进行分析也很轻松。 4. 对于相同的数据集来说AOF文件的体积通常要大于RDB文件的体积 5. 根据所使用的fsync策略AOF的速度可能会慢于RDB 总结 : 用哪个好
官方推荐2个都启用。如果对数据不敏感可以单独用RDB。不建议单独使用AOF因为可能会出现BUG。如果只是做纯内存缓存可以都不用。
官方建议 :
