双语版网站引导页,高台网站建设,用在线网站做的简历可以吗,福州网站设计软件公司目录
RDB 1.手动触发 2.自动触发
AOF
aof的重写机制 Redis虽然是一个内存数据库#xff0c;但是也是可以将数据存储到硬盘中的#xff0c;也就是持久化。硬盘的数据是在Redis重启的时候#xff0c;用来恢复内存中的数据的#xff0c;即对数据做了一个备份。Redis实现持…目录
RDB 1.手动触发 2.自动触发
AOF
aof的重写机制 Redis虽然是一个内存数据库但是也是可以将数据存储到硬盘中的也就是持久化。硬盘的数据是在Redis重启的时候用来恢复内存中的数据的即对数据做了一个备份。Redis实现持久化具体是按照RDB和AOF两种策略来实现的。当同时开启RDB和AOF的时候以AOF为主。 RDB 即Redis database是指定期把Redis中的数据写入硬盘中生成一个“快照”存储在硬盘中。后续Redis一旦重启了(内存数据没了),就可以根据刚才的“快照”把内存中的数据恢复回来。
redis加载RDB恢复数据的速度远远快于AOF的方式因为RDB是用二进制的方式来组织数据的AOF是使用文本的方式组织数据的。 “定期”具体说来又有两种方式 1.手动触发 程序员通过redis客户端执行特定的命令来触发快照生成。 主要有两个命令 saveredis会全力以赴的生成“快照生成”的操作此时就会阻塞redis的其他客户端的命令。会直接在当前进程中往同一个rdb文件中写入数据。 bgsavebg background(后面)不会影响redis服务器处理其他客户端的请求和命令。此处redis使用的是“多进程”的方式来完成并发编程。流程如下 1.判定当前是否已经存在其他正在工作的子进程。如果当前已经有一个子进程正在执行bgsave此时就直接把当前的bgsave返回。 2.如果没有其他的工作进程就通过fork这样的系统调用创建出一个子进程。fork是linux系统提供的一个创建子进程的api。fork创建子进程直接把当前的进程父进程复制一份作为子进程子进程的内存里会存储和父进程一样的数据。一旦复制完成了父子进程就是两个独立的进程就各自执行各自的了。接下来安排子进程去执行“持久化”操作。 3.子进程负责进行写RDB文件生成快照的过程。父进程继续接收客户的请求正常提供服务。 4.子进程完成整体的持久化过程之后会通知父进程父进程就会更新一些统计信息。子进程就可以结束销毁了。 注 rdb持久化操作可以触发很多次。当执行生成rdb镜像操作的时候此时就会把要生成的快照数据先保存到一个临时文件中。当这个快照快要生成完毕的时候再删除之前的rdb文件把新生成的临时的rdb文件名字改成dump.rdb。就可以保证自始至终redis中的rdb文件只有一个。 2.自动触发 自动触发即在Redis配置文件中设置一下让Redis每个多长时间/每产生多少次修改就触发。 在redis的官方配置文件redis.conf中关于RDB自动触发的机制是
save seconds changes
save 900 1
save 300 10
save 60 10000 seconds代表触发所需的秒数changes表示在seconds时间内内存中key修改的次数。save 900 1 表示在900s内至少存在一次key的修改则在900s后会执行备份。 以上的数值都可以修改。但是我们的原则是不能让快照操作执行的太频繁。
注1.不仅仅是save执行一定时间内修改n次的方法通过shutdown命令关闭redis服务器的命令也能触发生成快照。
2. 当redis进行主从复制的时候主节点也会自动生成rdb快照然后把rdb快照内容传输给从节点。
3. save 表示关闭自动生成快照。
如果通过以上正常流程重新启动redis服务器此时redis服务器会在退出的时候自动触发生成rdb操作。但是如果是异常重启kill -9 或服务器掉电此时redis服务器来不及生成rdb内存中尚未保存到快照中的数据就会随着重启而丢失。 AOF RDB的最大问题在于不能实时的持久化保存数据。在两次生成快照之间实时的数据可能会随着重启而丢失。
AOF(append only file) 会把用户的每个操作都记录到文件中。当redis重新启动的时候就会读取这个aof文件中的内容用来恢复数据。
当开启aof的时候rdb就不生效了。aof默认是关闭状态修改配置文件来开启aof功能。
AOF并不会影响到redis处理请求的速度原因
1. AOF机制并非是直接让工作线程把数据写入硬盘而是先写入一个内存中的缓冲区积累一波之后再统一写入硬盘。 2. 硬盘上读写数据顺序读写的速度是比较快的随机访问的速度是比较慢的。AOF是每次把新的操作写入到原有文件的末尾属于顺序写入。
由于缓冲区是在内存中如果主机突然掉电数据就会丢失。redis给出了一些选项让程序员根据实际情况来决定如何取舍也就是缓冲区的刷新策略刷新频率越高性能影响就越大同时数据的可靠性就越高。 always相当于立即刷新频率最高数据可靠性最高性能最低。
everysec 相当于每秒刷新。
no相当于由操作系统自行决定刷新频率。频率最低数据可靠性最低性能最高。
默认策略是everysec。
aof的重写机制
redis启动的时候要读取aof文件的内容但是aof文件中的内容可能存在冗余。redis就存在一个机制能够针对aof文件进行整理操作这个机制就是能够剔除其中的冗余操作并且合并一些操作达到给aof文件瘦身的效果。也就是重写机制rewrite。
重写机制的触发方式分为手动触发和自动触发。
AOF重写的流程 使用fork的方式创建子进程父进程仍然负责接收请求子进程负责针对aof文件进行重写。而此时内存中的数据的状态就已经相当于是把AOF文件结果整理后的模样了。所以子进程只需要把内存中当前的数据获取出来以AOF的格式写入到一个新的AOF文件中。 非常类似于RDB生成快照的过程只不过RDB是按照二进制的方式生成的。AOF则是按照AOF这里要求的文本格式来生成的。
在子进程写新aof的同时父进程仍然在不停的接收客户端新的请求。父进程还是会先把这些请求产生的AOF数据先写入到缓冲区再刷新到原有的AOF文件中。 在创建子进程的一瞬间子进程就继承了当前父进程的内存状态。因此子进程里的内存数据是父进程fork之前的状态。fork之后新来的请求对内存造成的修改是子进程不知道的。
此时父进程这里又准备了一个aof_rewrite_buf缓冲区专门放fork之后收到的数据专门往新的aof文件去写。
子进程这边把aof数据全部写完之后会通过信号通知父进程。父进程再把aof_rewrite_buf缓冲区中的内容也写入到新AOF文件在里。
然后就可以用新的AOF文件代替旧的AOF文件了。
问题
1、如果在执行aof_rewrite_buf的时候当前redis已经在进行aof重写了会怎样呢
此时不会再次执行aof重写直接返回了。
2、如果在执行aof_rewrite_buf的时候发现当前redis在生成rdb文件的快照会怎样呢
此时aof重写操作就会等待等待rdb快照生成完毕之后再进行执行aof重写。
3、为什么rdb不在fork之后也采用类似aof_rewrite_buf缓冲区的方式来处理新数据呢
rdb本身的设计理念就是用来“定期备份”的。之要是定期备份就难以和最新的数据保持一致。
4、父进程在fork后继续写这个即将消亡的旧的aof文件是否还有意义
考虑到极端情况假设在重写到一半的时候服务器突然掉电子进程内存的数据就会丢失新的aof文件内容还不完整所以如果父进程不坚持写旧aof文件重启就没法保持数据的完整性了。 以上关于redis希望对你有所帮助。
