redi事务机制

技术文章 1年前 (2020) 完美者
1,012 0

标签:rdb   ued   资源   完成后   故障   出错   错误   完全   要求   

事务的acid特性:原子性,一致性,隔离性,持久性

原子性的要求很明确,就是一个事务中的多个操作必须都完成,或者都不完成。

一致性:指数据库中的数据在事务执行前后是一致的。

隔离性:它要求数据库在执行一个事务时,其它操作无法存取到正在执行事务访问的数据。

持久性:数据库执行事务后,数据的修改要被持久化保存下来。当数据库重启后,数据的值需要是被修改后的值

redis提供了multi与exec两个命令来完成事务的三个步骤:
第一步:客户端要使用一个命令显式地表示一个事务的开启。在 Redis 中,这个命令就是 MULTI。

第二步:客户端把事务中所要执行的操作发送给服务器端,但是这些命令会被redis实例放入一个命令队列,不会立即执行

第三部:客户端向服务器端发送提交事务的命令,让数据库实际执行第二步中发送的具体操作。Redis 提供的 EXEC 命令就是执行事务提交的。当服务器端收到 EXEC 命令后,才会实际执行命令队列中的所有命令。

redis对原子性保证的探究:
Redis 对事务原子性属性的保证情况:

命令入队时就报错,会放弃事务执行,保证原子性(比如执行redis不提供的命令,在入队时报错,但是不影响后续命令操作的添加。最后执行时放弃执行);

命令入队时没报错,实际执行时报错,不保证原子性(操作元素的命令不正确,对于String使用Lpop 则入队时不报错,执行时出错,但是后续命令如果正确可以执行,遮掩就保证不了原子性);

EXEC 命令执行时实例故障,如果开启了 AOF 日志,可以保证原子性(如果开启aof后,执行失败后的事务,只有部分操作会被记录到aof日志中,使用redis-check-aof工具可以检查aof日志,将之前完成的操作进行去除,这样的的话,使用aof恢复实例后,事务操作就不会被执行,从而保证了原子性)。

redis对一致性保证的探究:
事务的一致性保证会受到错误命令、实例故障的影响。

情况一:命令入队时就报错在这种情况下,事务本身就会被放弃执行,所以可以保证数据库的一致性。

情况二:命令入队时没报错,实际执行时报错在这种情况下,有错误的命令不会被执行,正确的命令可以正常执行,也不会改变数据库的一致性。

情况三:EXEC 命令执行时实例发生故障在这种情况下,实例故障后会进行重启,这就和数据恢复的方式有关了,我们要根据实例是否开启了 RDB 或 AOF 来分情况讨论下。
如果我们没有开启 RDB 或 AOF,那么,实例故障重启后,数据都没有了,数据库是一致的。

如果我们使用了 RDB 快照,因为 RDB 快照不会在事务执行时执行,所以,事务命令操作的结果不会被保存到 RDB 快照中,使用 RDB 快照进行恢复时,数据库里的数据也是一致的(这里的一致是指故障前后的数据库状态)。

AOF 日志,而事务操作还没有被记录到 AOF 日志时,实例就发生了故障,那么,使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志,我们可以使用 redis-check-aof 清除事务中已经完成的操作,数据库恢复后也是一致的。

redis对隔离性保证的探究:

事务的隔离性保证,会受到和事务一起执行的并发操作的影响。而事务执行又可以分成命令入队(EXEC 命令执行前)和命令实际执行(EXEC 命令执行后)两个阶段,所以,我们就针对这两个阶段,分成两种情况来分析:

并发操作在 EXEC 命令前执行,此时,隔离性的保证要使用 WATCH 机制来实现,否则隔离性无法保证;(在进行事务执行之前,使用watch监听数据,在执行事务之前的命令入队阶段(该命令操作watch的数据),如果有并发线程对数据

有修改操作,那么watch就会知道数据被其他线程而修改,而放弃本次事务)

并发操作在 EXEC 命令后执行,此时,隔离性可以保证。很容易想到

redis对持久性保证的探究:
持久性因为 Redis 是内存数据库,所以,数据是否持久化保存完全取决于 Redis 的持久化配置模式。如果 Redis 没有使用 RDB 或 AOF,那么事务的持久化属性肯定得不到保证。如果 Redis 使用了 RDB 模式,那么,在一个事务执行后,而下一次的 RDB 快照还未执行前,如果发生了实例宕机,这种情况下,事务修改的数据也是不能保证持久化的。如果 Redis 采用了 AOF 模式,因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况,所以,事务的持久性属性也还是得不到保证。所以,不管 Redis 采用什么持久化模式,事务的持久性属性是得不到保证的。

扩展:

在使用redis时建议结合pipeline使用,上面的是使用multi开启一个事务,然后客户端收到一个ok,然后客户端逐个逐个的将命令发送给redis实例,客户端依次收到queued,最后客户端发送exec‘执行事务,这样消息每次都是一来一回,效率比较低,而且在这多次操作之间,别的客户端可能就把原本准备修改的值给修改了,所以无法保证隔离性。而使用pipeline是一次把所有命令都打包好发送给服务器端,服务器端全部处理完成后返回,这样减少了来回网络io次数,提高操作性能,而是一次性发送所有命令

到服务器端,服务器端在处理过程中,是不会被其他请求打断的,因为redis是单线程,这本身就保证了隔离性。(对于exec的理解,是redis实例执行队列中的操作,在执行过程中不会被其他请求打断,所以并发操作的影响如上面所说是在队列中时,其他线程对事务数据的修改,造成无法保证隔离性)

开启multi后,逐条逐条命令入队,然后exec执行,也就是使用了事务命令,但没有配合 Pipeline 使用,如果想要保证隔离性,需要使用 WATCH 命令保证。但是使用了 Pipeline 一次发送所有命令到服务端,那么就不需要使用 WATCH 了,因为服务端本身就保证了隔离性。

事务 + Pipeline 就可以保证隔离性,那 WATCH 还有没有使用的必要?答案是有的。对于一个资源操作为读取、修改、写回这种场景,如果需要保证事物的原子性,此时就需要用到 WATCH 了。例如想要修改某个资源,但需要事先读取它的值,再基于这个值进行计算后写回,如果在这期间担心这多条命令中的某个资源被其他客户端修改了,那么可以先 WATCH 这个资源,再读取、修改、写回,如果写回成功,说明其他客户端在这期间没有修改这个资源。如果其他客户端修改了这个资源,那么这个事务操作会返回失败,不会执行,从而保证了原子性。(这个例子也可以用pipeline)

 

redi事务机制

标签:rdb   ued   资源   完成后   故障   出错   错误   完全   要求   

原文地址:https://www.cnblogs.com/foreverlearnxzw/p/13901135.html

版权声明:完美者 发表于 2020-10-31 2:09:57。
转载请注明:redi事务机制 | 完美导航

暂无评论

暂无评论...