Redis的事务

Redis的事务

事务的概念

可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞。

作用

一个队列中,一次性、顺序性、排他性的执行一系列命令。

如何使用事务

常用命令

Case1 正常执行

批处理一个命令集合,在一个原子操作里各取所需,统统完成。

Case2 放弃事务

Case3全体连坐

  原子操作中的所有命令中,只要有一个命令没有成功执行(此命令在执行之前就已经报错,比如语法错误),那么其他的所有命令都不会被成功执行。

Case4 源头债主

  在原子操作中,如果某个命令在执行前未报错,而在执行的时候报错了,那么原子操作中的其他命令可以正常的执行,只有这个执行时报错的命令会执行失败。所以redis是部分支持事务,并不是强一致性。

Case5 watch监控

(1)悲观锁/乐观锁/CAS(Check And Set)

  悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

  乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,乐观锁策略:提交版本必须大于记录当前版本才能执行更新,如果提交版本不大于记录的当前版本,那么需要先去获取当前最大的版本的记录,再去修改这条记录。

(2)watch命令描述

  WATCH命令可以监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执行。监控一直持续到EXEC命令(事务中的命令是在EXEC之后才执行的,所以在MULTI命令后可以修改WATCH监控的键值)。

举一个案例:

  信用卡余额和应还额度,每使用一次银行卡消费,余额就减少消费的额度,应还额度同时要增加。首先初始化信用卡可用余额和欠额。

  设置balance=100,debt=0

1)无加塞篡改,先监控再开启multi,保证两笔金额变动在同一个事务内

2)有加塞篡改,监控了key,如果key被修改了,后面一个事务的执行失效

3unwatch

  对某个key开启监控,当开启某个事务之前,如果有人加塞修改了这个key的值,那么新开启的事务是不会执行成功的,可以在事务开始之前,对这个key先执行unwatch,然后再次watch key,再开启事务执行。

unwatch一旦执行了,exec之前加的监控锁都会被取消掉了。

小结

  Watch指令,类似乐观锁,事务提交时,如果Key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行。

通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

事务的三个阶段

(1)开启:以MULTI开始一个事务

(2)入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面

(3)执行:由EXEC命令触发事务

事务的三特性

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

(2)没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题。

(3)不保证原子性(部分支持事务):redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚。

 

原文地址:https://www.cnblogs.com/yxym2016/p/13556995.html