redis持久化机制 & 事务详解

目录

前言:

持久化机制

RDB(Redis DataBase)

手动触发 

save

bgsave

自动触发

RDB特点

AOF(append only file)

缓冲区刷新策略

重写机制

aof重写流程

混合持久化

事务

事务操作命令

WATCH

WATCH实现原理


前言:

    redis为了保证高可用引入了持久化机制,目的就是为了redis服务器重启时可以恢复原有的数据。redis提供了RDB,AOF和混合持久化三种机制,开发者可在不同的业务场景具体选择使用哪一个持久化机制。

持久化机制

RDB(Redis DataBase)

    定期备份,每隔一段时间将内存中的数据刷新到硬盘中,生成一个快照rdb文件(用来恢复数据)。

手动触发 

save

    执行save的时候,redis会全力以赴的进行“快照生成”的操作,此时就会阻塞其他客户端的命令,因为redis是单线程模型。(一般不建议)

bgsave

1)不会影响redis处理其他客户端的命令。redis在后台采用多进程方式生成rdb文件。

2)redis将内存中的数据以压缩的方式保存到二进制文件中(镜像文件,rdb文件)。

3)redis服务器重启时,需要加载这个快照文件,如果快照文件格式不对,redis服务可能会启动失败。同时redis提供了rdb文件检查工具,可以手动执行进行rdb文件校验。

执行流程

    当生成rdb镜像文件时,首先会保存在一个临时文件中,当快照生成完毕后。然后删除原来的rdb文件,将临时文件替换为新的rdb文件。(始终rdb文件只有一个)

    多进程处理bgsave。当触发bgsave命令时,redis首先会判断是否有其他进程在执行rdb文件操作,如果有其他正在运行的进程则直接返回。

    redis会fork一个和当前进程一模一样的子进程(文件描述符表,虚拟内存地址等等进程信息都是一致的)。并且也是共用同一块内存空间(防止内存数据量太大fork时就比较消耗资源),只有当父进程修改了内存中的数据时,此时子进程就会复制内存中的数据,不在和父进程共享同一块内存了。当子进程处理完rdb文件时,使用信号通知父进程,父进程就可以销毁这个子进程了。

redis持久化机制 & 事务详解_第1张图片

redis生成快照操作触发时机:

1)配置文件中M时间内修改N次,自动触发。

2)通过shutdown命令正常停止redis服务。

3)redis进行主从复制的时候,主节点会自动生成rdb快照,然后把rdb快照传输给从节点。

自动触发

    在redis配置文件中,设置每隔多长时间/数据修改多少次就触发。

redis持久化机制 & 事务详解_第2张图片

RDB特点

1)RDB是一个紧凑压缩的二进制文件,代表redis在某个时间点上的数据快照。非常适用于备份,全量复制等场景。

2)redis加载RDB文件恢复数据远远快于AOF的方式。(主要由于RDB是二进制文件)

3)RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要fork子进程,属于重量级操作,频繁执行成本过高。

4)RDB用特定的二进制文件保存,redis是有多个版本的,存在兼容性问题。

注意:

    rdb持久化机制不能做到实时持久化,每次持久化操作之间都会存在时间间隔。那么在时间间隔内,如果redis服务器宕机了,这段间隔时间内数据还没有生成rdb文件,那么服务器重启就会丢失数据。

AOF(append only file)

    AOF是一个文本文件,每次进行redis操作,都会被追加到文件末尾(直接追加操作redis命令)

注意:

    redis首先将内存中的数据写入内存中的缓冲区,积累一波后,再统一写入到硬盘中。(大大降低了写硬盘的次数)

    AOF每次将新的操作追加到文件末尾,属于顺序写入,效率相对较高。

缓冲区刷新策略

可配置值                                             说明
always 命令写入aof_buf 后调用fsync同步,完成后返回
everysec 命令写入aof_buf 后只执行write操作,不进行fsync,每秒由同步线程进行fsync
no 命令写入aof_buf 后只执行write操作,由操作系统控制fsync频率

注意:

    上述缓冲区刷新策略由快到慢,那么数据可靠性由高到低,性能由低到高。配置文件中都是可修改的。

重写机制

    aof文件中存在一些冗余的记录(一些命令的中间状态也都保存了),redis重写机制针对aof文件进行整理,达到瘦身的效果。

    aof文件中数据只关注内存中最终状态,因此只需要将内存中的数据状态写入新aof文件,替换掉原来的就可以。

触发时机:

    手动触发:bgrewriteaof命令。

    自动触发:配置文件中进行配置(触发时aof最小文件大小,aof相比于上次文件大小增加的比例)

aof重写流程

    父进程会fork一个子进程,子进程将此刻内存数据按照aof格式写入到新aof文件。同时父进程继续处理命令,同时也写入到aof_rewrite_buf和旧aof文件中。

    当子进程将新aof文件写入完毕,使用信号通知父进程,然后将父进程写入的aof_rewrite_buf合并到新aof文件,然后替换掉旧aof文件。

问:为什么父进程需要写旧aof文件,不是最后要替换掉吗?

    如果子进程写新aof文件,突然进程挂了,那么aof文件就是不完整的。如果没有旧aof文件,数据就丢失了。

redis持久化机制 & 事务详解_第3张图片 

注意:

    重写只关注内存中的最终状态,不关注aof文件中原来有啥。

    如果,在执行bgrewriteaof的时候,已经在执行aof重写了,此时不会再次执行aof重写,直接返回了。

    如果,在执行bgrewriteaof的时候,redis正在生成rdb快照,此时redis的aof重写就会等待,等待rdb文件生成完毕,再执行aof重写。

混合持久化

    结合了aof和rdb机制的特点。

    按照aof的方式将每一步操作都记录到文件中。在触发aof重写机制后,就会把当前内存的状态按照rdb的二进制格式写入到文件中,后续再操作仍然是按照aof文本追加的方式写入文件。

注意

    当redis上同时存在aof和rdb文件时,以aof为主,rdb就被忽略了。

事务

    把多个操作打包到一起,要么全都执行,要么全都不执行。如果执行若干条命令,失败了,那就失败了,没有任何处理。(由于和mysql相比这里没有回滚操作,那么认为redis事务没有原子性)。

    不具备一致性:redis没有约束,也没有回滚机制。事务执行过程中如果某个修改操作失败,就会导致不一致的情况。

    不具备持久性:redis是内存数据库,数据存储在内存中的。虽然有持久化机制,但也是为了redis恢复数据,和这里没有关系。

    不涉及隔离性:redis是单线程处理请求命令,所有请求都是串行执行的,不涉及并发。

redis事务主要意义:

    就是为了打包命令,防止其他客户端命令插队。

注意:

    redis实现事务引入了队列(每个客户端都有一个)。开启事务的时候,客户端请求命令就会进入到这个队列,而不会立即执行,当提交事务的时候,redis才会打包一起按照顺序执行这些命令。主线程会把这些命令处理完,再处理其他客户端请求。

    redis如果按照集群模式部署,不支持事务。

事务操作命令

开启事务:MULTI

提交事务:EXEC

放弃当前事务:DISCARD

注意:

    当开启事务,并且客户端发送若干条命令后,如果redis服务重启,那么就会放弃当前的事务(DISCARD)。

WATCH

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

    如果在事务执行时发现了某个key被其他客户端修改了,那么事务提交时就不会真正执行这条修改命令。

WATCH实现原理

    基于版本号机制实现类似“乐观锁”。预测锁竞争不是很激烈,即其他客户端在事务提交之前修改相同数据概率不是很大。

    当使用watch监控某个key时,会给这个key分配一个版本号,如果有其他客户端修改了这个key,则版本号会变大。当exec提交事务的时候就会判断,这个key版本号是否和之前watch记录的版本号一致。

    如果一致则说明key没有被修改过,就会正常执行事务中的命令。如果不一致则说明key被其他客户端修改过,就会直接丢弃事务中的操作,exec返回nil。

你可能感兴趣的:(redis,redis,数据库)