Redis-事务与持久化

2022-01-06 00:00:00 数据 执行 命令 事务 进程

Redis中的事务与持久化

Redis中的事务

事务的定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。Redis事务的主要作用就是串联多个命令防止别的命令插队。

事务的执行方法

  • Redis中操作事务主要是由三个命令来执行的,分别为Multi、Exec、discard,从输入Multi命令开始,输入的命令都会依次进入命令队列中,但是不会执行,直到输入Exec命令之后,Redis会将之前命令队列中的命令依次的执行.组队的过程中可以通过Discard命令来放弃组队

  • 添加到队列成功时,提交成功

  • 组队阶段时提交命令报错

  • 组队时提交命令没有失败,但是执行时失败

事务的错误处理

  • 当组队时某个命令出现了错误(命令拼错或者其他情况),执行时整个所有队列都会被取消
  • 当执行时某个命令出现了错误,只有出现错误的命令不会被执行,其他的命令都会执行,不会回滚

事务中冲突问题的解决(锁机制)

  • Redis中使用乐观锁的机制来去实现事务,即次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制.乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

WATCH key [Key...]

  • 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。下图在首先监视k1,在进行事务操作时,另一个连接对k1进行了操作,在执行操作时,对k1的赋值失败

unwatch


  • 取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

Redis中事务的三大特性

  • 单独的隔离操作
    • 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
  • 没有隔离级别的概念
    • 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
  • 不保证原子性
    • 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

持久化之RDB

RDB的含义

  • 在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

RDB如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB 的缺点是后一次持久化后的数据可能丢失。

FORK

  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

RDB的配置

  • 配置临时文件的名称(生成备份文件的名称)

  • 快照文件的生成路径

  • 压缩、检查完整性、以及无法写入磁盘时关闭redis,检查完整性时会增加大约10%的性能消耗,如果希望获取到大的性能提升,可以关闭该功能

  • save命令 格式:save 秒钟 写操作次数(默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。), 禁用时:不设置save指令，或者给save传入空字符串

RDB备份后如何恢复

  • 先通过config get dir 查询rdb文件的目录
  • 将*.rdb的文件拷贝到别的地方
  • rdb的恢复
    • 关闭Redis
    • 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
    • 启动Redis, 备份数据会直接加载

RDB持久化的优势和劣势

  • 优势
    • 适合大规模的数据恢复
    • 对数据完整性和一致性要求不高更适合使用
    • 节省磁盘空间
    • 恢复速度快
  • 劣势
    • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
    • 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
    • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失后一次快照后的所有修改。

停止RDB持久化

  • redis-cli config set save ""#save后给空值，表示禁用保存策略

持久化之AOF

AOF是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF的持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF补充

  • AOF默认不开启
  • 可以在redis.conf中配置文件名称,默认为appendonly.aof
  • AOF的文件保存路径与RDB的路径一致
  • AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)

AOF启动/修复/恢复

  • AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
  • 正常恢复
    • 修改默认的appendonly no，改为yes
    • 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
    • 恢复：重启redis然后重新加载
  • 异常恢复
    • 修改默认的appendonly no，改为yes
    • 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
    • 备份被写坏的AOF文件
  • 恢复：重启redis，然后重新加载

同步频率设置

  • appendfsync always  始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
  • appendfsync everysec 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  • appendfsync no  redis不主动进行同步，把同步时机交给操作系统。

优势

  • 备份机制更稳健，丢失数据概率更低。
  • 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

  • 比起RDB占用更多的磁盘空间。
  • 恢复备份速度要慢。
  • 每次读写都同步的话，有一定的性能压力。
  • 存在个别Bug，造成恢复不能。

与RDB比较

官方推荐两个都启用。如果对数据不敏感，可以选单独用RDB。不建议单独用 AOF，因为可能会出现Bug。如果只是做纯内存缓存，可以都不用。

来源：https://mp.weixin.qq.com/s/Uwr7QlkM4A3Yneaz6-Sipg

相关文章