目录
RDB叫做Redis数据备份文件,也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。快照文件称为RDB文件,默认是保存在当前运行目录
通过redis客户端,执行特定的命令,来触发快照生成
执行save的时候,redis就会全力以赴的执行“快照生成”操作,此时就会阻塞redis的其他客户端的命令(一般不建议使用save)
运作流程:
1.执行bgsave命令, Redis 父进程判断当前进是否存在其他正在执行的子进程,如RDB/AOF子进星,如果存在bgsave命令直接返回。
2.父进程执行fork创建子进程,fork 过程中父进程会阻塞,通过info stats命令查看latest_fork_usec 选项,可以获取最近一次fork操作的耗时,单位为微秒。
3.父进程fork完成后,bgsave命令返回"Background saving started"信息并不再阻塞父进程,可以继续响应其他命令。
4.子进程创建RDB文件,根据父进程内存生成临时快照文件。完成后对原有文件进行原子替换。执行lastsave命令可以获取最后-次生成RDB的时间,对应info统计的rdb_ last_save_time选项。
5.进程发送信号给父进程表示完成,父进程更新统计信息。
在redis配置文件中,设置一下,让redis,每隔多长时间/没产生多少次修改就触发
RDB问题:不能实时的持久化保存数据,在两次生成快照之间,实时的数据可能会随着重启而丢失
类似于mysql的binblog,就会把用户的每个操作,都记录到文件中。当redis重新启动的时候,就会读取这个aof文件中的内容,用来恢复数据。
默认此功能是关闭的,修改配置文件来开启aof功能
1、AOF 机制并非是直接让工作线程把数据写入硬盘,而是先写入一个内存中的缓冲区,积累到一定数量的时候,再统一写入硬盘;
2、AOF 每次是把新的操作命令顺序写入原有文件的末尾,输入顺序写入,这样的方式相比于随机访问的速度要快很多的
redis 给出了一些选项,让我们可以根据实际情况来决定怎么取舍——缓冲区刷新策略:
1、always 每操作一次就保存一次:频率是最高的,数据可靠性最高,性能最低.
2、everysec 每秒保存一次:频率低一些,数据可靠性降低,性能会提高.
3、?no 跟随系统的同步策略:频率最低,数据可靠性最低,性能是最高的.
此机制能够针对aof文件进行整理操作,这个整理就是能够剔除其中的冗余操作,并且合并一些操作,达到给aof文件瘦身的效果
Redis也会在触发阈值时自动去重写AO文件,阈值也可以在redis.conf中配置:
流程
结合了rdb和aof的特点,按照aof的方式,每一个请求/操作,都记录入文件,在触发aof重写后,就会把当前内存的状态按照rdb的二进制格式写入到新的aof文件中,后续再进行的操作,仍然是按照aof文本的方式追加到文件后面
本质上是在服务器上搞了一个“事务队列”,每次客户端在事务中进行了一个操作,都会把命令先发给服务器,放到“事务队列”中(但是并不会立即执行),而是会在真正收到EXEC命令之后,才真正执行队列中的所有操作
redis事务和mysql事务的区别:
弱化的原子性:redis没有“回滚机制”,只能做到这些操作“批量执行”,不能做到“一个失败就恢复到初始状态”;
不保证一致性:不涉及“约束”,也没有回滚。MySQL的一致性体现的是运行事务前和运行后,结果都是合理有效的,不会出现中间非法状态;
不需要隔离性:也没有隔离级别,因为不会并发执行事务(redis单线程处理请求);
不需要持久性:是保存在内存的,是否开启持久化,是redis-server自己的事情,和事务无关
开启事务
执行事务
放弃当前事务
监控某个key是否在事务执行之前,发生了改变