Redis的持久化和事务

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

两种持久化方式

Redis有两种持久化方式，RDB和AOF

RDB(Redis DataBase)

RDB默认将数据保存到dump.rdb文件中

可以理解为将数据备份到磁盘，通过使用该文件就可以将磁盘中的数据恢复到Redis中

相关配置

################################ SNAPSHOTTING  ################################
#
# 保存 DB 到硬盘:
#
# save <seconds> <changes>
#
# 将会在<seconds> 和 <changes>两个值同时满足时，将DB数据保存到硬盘中
# 其中<seconds> 每多少秒，<changes>是改变的key的数量
#
# 在以下的例子中，将会存在如下的行为
# 当存在最少一个key 变更时，900秒(15分钟)后保存到硬盘
# 当存在最少10个key变更时，300秒后保存到硬盘
# 当存在最少1000个key变更时，60秒后保存到硬盘
#
# 提示: 你可以禁用如下的所有 save 行
#
# 你可以删除所有的save然后设置成如下这样的情况
#
# save ""
save 900 1
save 300 10
save 60 10000

在redis-cli中使用save或bgsave均可立即保存数据（bdsave 后台执行保存数据的动作）

持久化流程

Redis会单独创建（fork）一个子进程来进行持久化

子进程会先将数据写到一个临时文件中，待持久化过程结束后用这个临时文件替换掉上次的.rdb文件

持久化过程中，主进程不进行IO操作。

由于RDB持久化每次会批量持久化数据，所以缺点是最后一次的持久化数据可能丢失。且由于每次fork时内存中的数据都会被克隆一份，数据会有2倍大小

AOF(Append Only File)

AOF将用户执行增删改的命令追加到appendonly.aof文件中

文件中存着用户使用过的除读操作外的历史命令的日志，重启redis-server后，Redis会读取并执行该文件中的命令，达到恢复数据的效果

相关配置

############################## APPEND ONLY MODE ###############################
# 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。
# 但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，
# Append Only File是另一种持久化方式，可以提供更好的持久化特性。
# Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，
# 每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly yes
# aof文件名(default: "appendonly.aof")
appendfilename "appendonly.aof"
# aof持久化策略的配置
# no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
# always 表示每次写入都执行fsync，以保证数据同步到磁盘。
# everysec 表示每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec

缺点

AOF使用的.aof文件的大小远大于.rdb文件的大小

持久化的使用方式

使用这两个文件恢复数据的方式：

将他们的文件放在redis目录下时，重启redis即可

两种持久化可同时使用，默认优先使用aof文件恢复数据

==注：如果你执行了fulhall（快乐删库）这条命令也会被追加到aof文件中或体现在.rdb文件中==

如果.aof或.rdb文件在备份时被写坏，导致Redis启动报错。使用redis-check-aof --fix <fileName>或redis-check-rdb --fix <fileName>修复文件

使用哪一种持久化方式

两种都用

Redis的事务

一个事务是一条或多条命令的集合，这一条或者多条命令要么全部执行成功，要么全部执行失败。

Redis的支持事务，但是是部分支持。Redis的事务不保证原子性

用关事务的命令

MULTI 开始事务

DISCARD 取消事务

EXEX 执行事务中的命令

WATCH key 监视指定的key，如果==事务开始前==key的值被其他人修改了，事务执行的时候会被打断，事务中所有命令执行失败

UNWATCH 取消对所有key的WATCH

Redis事务的特点

Redis对事务的支持是部分支持，不是完全支持

  • 如果在一个事务中的命令出现错误，那么所有的命令都不会执行

  • 如果在一个事务中出现运行错误，那么正确的命令会被执行

单独的隔离操作：事务中所有的命令多会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际的执行，也就是不存在 “ 事务内的查询要看到事务里面的更新，在事务外查询不能看到 ”

不保证原子性：Redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Watch监控

watch在上述事务命令中已经简单介绍过，这里不再赘述

锁的名称

描述

乐观锁

乐观。每次取数据的时候，会认为数据没有被修改过

悲观锁

悲观。每次取数据的时候，会认为数据都被修改过

CAS（Check And Set）

乐观锁的实现

加悲观锁，就是锁表。A在用数据，那B就不能用数据。因为悲观锁为防止取的数据是被修改过的而将数据锁上

加乐观锁，像git一样。A在改数据，结果B在A改之前改过了，那么A就要先拿到最新的数据然后再修改，提交。和git的pull，push的一样。因为乐观锁不会锁表，而会在改数据前检查一下能不能改

watch指令类似乐观锁

以上是 Redis的持久化和事务 的全部内容， 来源链接： utcz.com/z/519207.html

回到顶部