wordpress后台管理地址更改,班级优化大师怎么用,建设很行官方网站,如何提高网站关键词排名目录
一、RDB
RDB触发保存的两种方式
优劣势总结
二、AOF
AOF持久化流程#xff1a;
1、开启AOP
2、异常恢复
3、AOF的同步频率设置
4、ReWrite压缩
5、优劣势总结
Redis 4.0 混合持久化 redis是内存数据库#xff0c;所有的数据都会默认存在内存中#xff0c;如…
目录
一、RDB
RDB触发保存的两种方式
优劣势总结
二、AOF
AOF持久化流程
1、开启AOP
2、异常恢复
3、AOF的同步频率设置
4、ReWrite压缩
5、优劣势总结
Redis 4.0 混合持久化 redis是内存数据库所有的数据都会默认存在内存中如果不进行持久化操作当出现断电等问题数据都不会保存
一、RDB 是指在时间间隔内将内存中的数据集快照写入磁盘。Redis会单独创建一个子进程来进行持久化会先将数据写入一个临时文件中待持久化都结束了再用这个临时文件替换上一次持久化好的文件。整个过程中主进程是不进行任何IO操作的这就确保了极高的性能如果需要进行大规模的数据恢复且对于恢复的完整性不是非常敏感那RDB方式要比AOF方式更加高效RDB的缺点是最后一次持久化后的数据可能会丢失。在redis启动的时候会自动将rdb文件的数据读到内存中。
RDB触发保存的两种方式
1、自动触发 进入配置文件中将sava注释打开 首先 在默认配置下我们很难演示这个过程所以需要对它进行修改 新增了一条配置在10秒内执行两次即可实现写入操作修改完配置之后重启redis进行测试
现在data目录下是没有文件的
在10秒内输入三条命令
会将数据写入dump.rdb文件中
每次触发保存只会保存两条根据save的条件进行保存。
-----------------------------------------------------------------------------------------------------------------------------
stop-writes-on-bgsave-error 默认值为yes。当启用了RDB且最后一次后台保存数据失败Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上否则没有人会注意到灾难disaster发生了。如果Redis重启了那么又可以重新开始接收数据了rdbcompression 默认值是yes。对于存储到磁盘中的快照可以设置是否进行压缩存储。如果是的话redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话可以设置为关闭此功能但是存储在磁盘上的快照会比较大。rdbchecksum 默认值是yes。在存储快照后我们还可以让redis使用CRC64算法来进行数据校验但是这样做会增加大约10%的性能消耗如果希望获取到最大的性能提升可以关闭此功能。dbfilename 设置快照的文件名默认是 dump.rdbdir设置快照文件的存放路径这个配置项一定是个目录而不能是文件名。默认是和当前配置文件保存在同一目录。也就是说通过在配置文件中配置的 save 方式当实际操作满足该配置形式时就会进行 RDB 持久化将当前的内存快照保存在 dir 配置的目录中文件名由配置的 dbfilename 决定。
2、手动触发①、save 该命令会阻塞当前Redis服务器执行save命令期间Redis不能处理其他命令直到RDB过程完成为止。 显然该命令对于内存比较大的实例会造成长时间阻塞这是致命的缺陷为了解决此问题Redis提供了第二种方式。②、bgsave 执行bgsave命令的时候,redis会自己fork出一条子进程,由这条子进程去执行,这样就不会影响到客户端对于redis 的正常操作 有意思的是,我们都知道,进程与进程之间的内存不是共享的,那么子进程是如何获取到主进程的内存数据呢? 真像是在主进程fork子进程的同时,会把自己内存中的数据同时复制一份给子进程,这样就相当于子进程可以读取到主进程的数据了,然后子进程就可以愉快的进行io操作了.(将内存中的数据写入磁盘中).有的小伙伴可能会问,那么这个复制内存的操作是立即执行的吗,其实并不是的,正常情况下redis的服务大部分都是读操作,在fork子进程的时候,子进程其实并没有直接复制一份主进程的数据,而是给他分配了一个虚拟的内存地址,指向了父进程的内存地址,如果在fork期间客户端发起了新的操作,父进程的内存数据发生改变的时候才会进行复制内存的操作,此时子进程使用副本内存进行写入rdb文件而主进程使用原始内存继续进行写入操作。为了性能,基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令,也就是自动提交。 写时复制 kernel把父进程中所有的内存页的权限都设为read-only然后子进程的地址空间指向父进程。当父子进程都只读内存时相安无事。当其中某个进程写内存时CPU硬件检测到内存页是read-only的于是触发页异常中断page-fault陷入kernel的一个中断例程。中断例程中kernel就会把触发的异常的页复制一份于是父子进程各自持有独立的一份。rdb就是采用了这种机制避免了双倍内存占用的现象 ③、flushall
执行执行 flushall 命令也会产生dump.rdb文件但里面是空的没有意义。
save于bgsave对比 命令 save bgsave IO类型 同步 异步 是否阻塞redis其它命令 是 否(在生成子进程执行调用fork函数时会有短暂阻塞) 复杂度 O(n) O(n) 优点 不会消耗额外内存 不阻塞客户端命令 缺点 阻塞客户端命令 需要fork子进程消耗内存
优劣势总结
优势
适合大规模数据恢复对数据完整性和一致性要求不高更适合使用节省磁盘空间rdb文件一般来说都会比aof文件要小很多数据恢复快
劣势
数据不完整性在fork子进程的时候需要消耗两倍的内存。
二、AOF 以日志的形式来记录每个写操作增量保存将Redis执行过的所有指令记录下读操作不记录只需追加文件但不可以改写文件Redis启动之初会读取该文件重新构建数据换言之redis重启的话就根据日志文件的内容将写指令从头到尾执行一次以完成数据恢复工作。
AOF持久化流程
客户端的请求写命令会被append追加到AOF缓冲区AOF缓冲区根据AOF持久化策略【alwayseverysecno】将操作sync同步到磁盘的AOF文件中AOF文件大小超过重写策略或手动重写时会对AOF文件rewrite重写压缩AOF容量redis服务重启时会重新load加载AOF文件中的写操作达到数据恢复的目的
1、开启AOP 在Redis中AOF是默认不开启的需要我们手动开启 搜索appendonly找到该位置 将no改成yes 重启redis即可看到aof文件 要点 当AOF和RDB同时开启的时候系统默认读取AOF的数据数据不会丢失所以之前如果用的是rdb持久化数据再转成AOF那么就读取不到之前的数据。
打开了之后每执行一指令就会自动持久化
2、异常恢复 当AOF文件出现异常的时候redis的客户端时不能正常连接的这时候需要我们修复文件
现在先模拟一下异常情况
①、先存入几条数据 ②、打开编辑aof文件 在里面加入自定义字符串让文件出错 然后重启一下redis重新启动redis客户端会发现已经不能连接了 ③、解决方案 容器启动不起来我们不能进入容器中的/usr/local/bin/找到redis-check-aof。但是有其他的方法
输入
docker inspect 容器id Ⅰ、先找到备份的aop叫什么名字以防不是默认文件名的情况 找到了data就是我们存放aof文件的位置而source就是宿主机数据卷的位置复制一下source的路径进入其中 可以看到aof文件这里我用的是默认名字 Ⅱ、找到修复文件工具redis-check-aof
我们知晓这个工具的具体名字 可以直接通过find命令找到 find / --name “文件名” 找到文件后直接执行
找到的文件名加上 --fix 后面跟着aof文件的路径执行即可 3、AOF的同步频率设置 1、appendfsync always
始终同步每次Redis的写入都会立刻计入日志性能较差但数据完整性较好。
2、appendfsync everysec
每秒同步每秒计入日志一次如果宕机本秒的数据可能会丢失
3、appendfsync no
redis不主动进行同步把同步时机交给操作系统
4、ReWrite压缩 Aof采用文件追加方式文件会越来越大为了避免出现这种情况新增了重写机制当AOF文件大小超过所设定的阈值时Redis就会启用AOF文件的内容压缩只保留可以恢复的数据的最小指令集也可以使用bgrewriteaof手动压缩
如何实现
AOF文件持续增长时会fork出一条新进程来将文件重写也就是先写入临时文件最后再rename而父进程继续接受命令现在的写操作命令都会被额外添加到一个aof_rewrite_buf_blocks缓冲中当子进程rewrite结束后父进程收到子进程退出信号把aof_rewrite_buf_blocks的缓冲添加到rewrite后的文件中然后切换AOF的文件fd。
重写策略 如上图所示上图配置的大体意思为当AOF文件大小超过了64m并且超过了64m的100%128m就开始重写。 # auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写文件太小恢复速度本来就很快重写的意义不大 # auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写 appendfsync-on-rewrite
同时在执行bgrewriteaof操作和主进程写aof文件的操作两者都会操作磁盘而bgrewriteaof往往会涉及大量磁盘操作这样就会造成主进程在写aof文件的时候出现阻塞的情形现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no是最安全的方式不会丢失数据但是要忍受阻塞的问题。如果设置为yes呢这就相当于将appendfsync设置为no这说明并没有执行磁盘操作只是写入了缓冲区因此这样并不会造成阻塞因为没有竞争磁盘但是如果这个时候redis挂掉就会丢失数据。丢失多少数据呢在linux的操作系统的默认设置下最多会丢失30s的数据
5、优劣势总结
优势
备份机制更加稳健丢失数据概率更低可读的日志文本通过操作AOF稳健可以处理错误操作
劣势
比起rdb更占用磁盘除了要记录数据还记录了指令恢复备份速度更慢每次读写都同步的话有一定的性能压力 Redis 4.0 混合持久化
重启 Redis 时我们很少使用 RDB来恢复内存状态因为会丢失大量数据。我们通常使用 AOF 日志重放但是重放 AOF 日志性能相对 RDB来说要慢很多这样在 Redis 实例很大的情况下启动需要花费很长的时间。 Redis 4.0 为了解决这个问题带来了一个新的持久化选项——混合持久化。
通过如下配置可以开启混合持久化(必须先开启aof) # aof-use-rdb-preamble yes 原理
如果开启了混合持久化AOF在重写时不再是单纯将内存数据转换为RESP命令写入AOF文件而是将重写这一刻之前的内存做RDB快照处理并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起都写入新的AOF文件新的文件一开始不叫appendonly.aof等到重写完新的AOF文件才会进行改名覆盖原有的AOF文件完成新旧两个AOF文件的替换。
于是在 Redis 重启的时候可以先加载 RDB 的内容然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放因此重启效率大幅得到提升。
混合持久化AOF文件结构如下
