redis中的事务
Posted dongyaotou
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了redis中的事务相关的知识,希望对你有一定的参考价值。
前言
Redis事务本质:一组命令的集合!一个事务中的所有命令都会被序列化,在事务执行过程中,会按照顺序执行!
一次性、顺序性、排他性!执行一系列的命令!
------队列 set set set 等等命令 执行----
Redis的事务没有隔离级别的概念!
所有的命令在事务中,并没有直接被执行!只有发起执行命令的时候才会执行!
Redis单条命令是保证原子性的,但是事务是不保证原子性的。
Redis事务:
(1)开启事务 multi
(2)命令入队
(3)执行事务 exec
127.0.0.1:6379[1]> flushdb OK 127.0.0.1:6379[1]> keys * (empty array) 127.0.0.1:6379[1]> multi #开启事务 OK #命令入队 127.0.0.1:6379[1]> set key1 value1 QUEUED 127.0.0.1:6379[1]> set key2 value2 QUEUED 127.0.0.1:6379[1]> get key2 QUEUED 127.0.0.1:6379[1]> set key3 value3 QUEUED 127.0.0.1:6379[1]> exec #执行事务 1) OK 2) OK 3) "value2" 4) OK
放弃事务:
127.0.0.1:6379[1]> set key1 aaa QUEUED 127.0.0.1:6379[1]> set key2 bbb QUEUED 127.0.0.1:6379[1]> set key4 ccc QUEUED 127.0.0.1:6379[1]> discard #取消事务 OK 127.0.0.1:6379[1]> get key1 "value1" 127.0.0.1:6379[1]> get key4 #可见事务中的命令都不会被执行 (nil) 127.0.0.1:6379[1]>
redis中的事务异常机制(和Java中的异常进行类比!)
编译型异常:代码有问题,也就是说命令有错误,事务中所有的命令都不会被执行
127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> set k1 v1 QUEUED 127.0.0.1:6379[1]> set k2 v2 QUEUED 127.0.0.1:6379[1]> set k3 v3 QUEUED 127.0.0.1:6379[1]> getset kk #命令语法错误 (error) ERR wrong number of arguments for ‘getset‘ command 127.0.0.1:6379[1]> set k4 v4 QUEUED 127.0.0.1:6379[1]> set k5 v5 QUEUED 127.0.0.1:6379[1]> exec #执行事务的时候报错 (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379[1]> get k4 #可见所有的命令都不会被执行 (nil) 127.0.0.1:6379[1]>
运行时异常:如果事务队列中存在语法性错误,那么执行命令的时候,其他命令是可以正常执行的,错误命令抛出异常!但是在mysql中,这是万万不能的
127.0.0.1:6379[1]> flushdb OK 127.0.0.1:6379[1]> set k1 v1 OK 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> incr k1 QUEUED 127.0.0.1:6379[1]> set k2 v2 QUEUED 127.0.0.1:6379[1]> set k3 v3 QUEUED 127.0.0.1:6379[1]> exec 1) (error) ERR value is not an integer or out of range #虽然第一条命令报错了,但是其他的命令依旧正常执行成功了! 2) OK 3) OK 127.0.0.1:6379[1]> get k2 "v2" 127.0.0.1:6379[1]> get k3 "v3"
监控:watch
悲观锁:很悲观,认为什么时候都会出现问题,无论做什么都会加锁!
乐观锁:很乐观,认为什么时候都不会出现问题,所以不会上锁!更新数据的时候会去判断一下,在此期间是否有人修改过这个数据!获取version,更新的时候比较version,如果version改变,则事务提交失败!
Redis测监视测试
正常执行成功
127.0.0.1:6379[1]> set money 100 OK 127.0.0.1:6379[1]> set moneyout 0 OK 127.0.0.1:6379[1]> watch money #监视 money 对象 OK 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> decrby money 20 QUEUED 127.0.0.1:6379[1]> incrby moneyout 20 QUEUED 127.0.0.1:6379[1]> exec #事务正常结束,数据期间没有发生变动,这个时候就正常执行成功! 1) (integer) 80 2) (integer) 20 127.0.0.1:6379[1]>
测试多线程修改值,使用watch可以当做redis的乐观锁进行操作
127.0.0.1:6379[1]> watch money #监视money OK 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> decrby money 10 QUEUED 127.0.0.1:6379[1]> incrby out 10 QUEUED 127.0.0.1:6379[1]> exec #执行之前,我们新开一个线程将money的值进行修改,这个时候事务就会执行失败 (nil)
新开的线程修改money的值:
127.0.0.1:6379[1]> set money 1000 OK 127.0.0.1:6379[1]> get money "1000"
如果修改失败,获取最新的值就好了
127.0.0.1:6379[1]> unwatch #如果发现事务执行失败,就先解锁 OK 127.0.0.1:6379[1]> watch money #获取最新的值,再次进行监视 相当于MySQL中的select version OK 127.0.0.1:6379[1]> multi OK 127.0.0.1:6379[1]> decrby money 10 QUEUED 127.0.0.1:6379[1]> incrby moneyout 10 QUEUED 127.0.0.1:6379[1]> exec #比对监视的值是否发生了变化,如果没有发生变化,那么可以执行成功,如果发生变化,就执行失败! 1) (integer) 990 2) (integer) 30 127.0.0.1:6379[1]>
以上是关于redis中的事务的主要内容,如果未能解决你的问题,请参考以下文章