深入Redis过程-持久化

目录

redis实现持久化

RDB

触发机制-定期方法

定期-手动触发

save

bgsave

定期-自动触发

AOF

开启AOF功能

刷新缓冲区策略

重写机制

混合持久化

Redis事务

事务相关的命令

MULTI

EXEC

DISCARD

WATCH

---

redis实现持久化

RDB

RDB叫做Redis数据备份文件，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录

触发机制-定期方法

定期-手动触发

通过redis客户端，执行特定的命令，来触发快照生成

save

执行save的时候，redis就会全力以赴的执行“快照生成”操作，此时就会阻塞redis的其他客户端的命令（一般不建议使用save）

bgsave

运作流程：

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问题：不能实时的持久化保存数据，在两次生成快照之间，实时的数据可能会随着重启而丢失

AOF

类似于mysql的binblog，就会把用户的每个操作，都记录到文件中。当redis重新启动的时候，就会读取这个aof文件中的内容，用来恢复数据。

开启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文本的方式追加到文件后面

Redis事务

本质上是在服务器上搞了一个“事务队列”，每次客户端在事务中进行了一个操作，都会把命令先发给服务器，放到“事务队列”中（但是并不会立即执行），而是会在真正收到EXEC命令之后，才真正执行队列中的所有操作

redis事务和mysql事务的区别：

弱化的原子性：redis没有“回滚机制”，只能做到这些操作“批量执行”，不能做到“一个失败就恢复到初始状态”；

不保证一致性：不涉及“约束”，也没有回滚。MySQL的一致性体现的是运行事务前和运行后，结果都是合理有效的，不会出现中间非法状态；

不需要隔离性：也没有隔离级别，因为不会并发执行事务（redis单线程处理请求）；

不需要持久性：是保存在内存的，是否开启持久化，是redis-server自己的事情，和事务无关

事务相关的命令

MULTI

开启事务

EXEC

执行事务

DISCARD

放弃当前事务

WATCH

监控某个key是否在事务执行之前，发生了改变