模拟一个买票的场景:现在只剩一张票ticket,票价100,zhang和li分别有300,决定去买票。如果当zhang买了,付钱的瞬间,li买了这唯一的一张票,并且付好了钱,提交了事务,那么zhang不是没有票了。
先启动redis-server服务,然后启动两个redis-cli服务
1.模拟数据:
127.0.0.1:6379> set ticket 1
OK
127.0.0.1:6379> set zhang 300
OK
127.0.0.1:6379> set li 300
OK
127.0.0.1:6379>
然后zhang开启事务,去买票,但是还没有提交事务exec:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr ticket
QUEUED
127.0.0.1:6379> decrby zhang 100
QUEUED
127.0.0.1:6379>
这个时候li迅速的买了票,并提交了事务:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr ticket
QUEUED
127.0.0.1:6379> decrby li 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 0
2) (integer) 200
127.0.0.1:6379>
可以看到 li买了票,这时ticket为0,这个时候zhang提交了事务exec:
127.0.0.1:6379> exec
1) (integer) -1
2) (integer) 200
127.0.0.1:6379>
发现ticket为-1,钱扣了100,也就是说付了钱,但是票没拿到。
通常为了避免这种情况,我们一般有两种做法:
1.给ticket加锁,也就是一个用户在使用ticket的时候,其他用户不允许使用(悲观锁)
2.用户在操作的同时监视着ticket,如果有其他用户更改了ticket,那么反馈给用户,ticket被更改了(乐观锁)
redis事务中启用的是乐观锁,只负责监视key有没有被改动
我们还是来模拟一下,首先flushdb,然后模拟相同的数据
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set ticket 1
OK
127.0.0.1:6379> set zhang 300
OK
127.0.0.1:6379> set li 300
OK
127.0.0.1:6379>
开启ticket的监视,然后zhang买票,但是不exec:
127.0.0.1:6379> watch ticket
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr ticket
QUEUED
127.0.0.1:6379> decrby zhang 100
QUEUED
127.0.0.1:6379>
这个时候 li买票并且exec:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr ticket
QUEUED
127.0.0.1:6379> decrby li 100
QUEUED
127.0.0.1:6379> exec
1) (integer) 0
2) (integer) 200
127.0.0.1:6379>
可以看到 li买好了票,钱也扣了,这个时候zhang exec:
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379>
发现提交事务的时候为nil,也就是没有执行这个事务,我们再来看一下zhang的钱有没有扣掉:
127.0.0.1:6379> mget ticket zhang
1) "0"
2) "300"
127.0.0.1:6379>
发现zhang的钱并没有被扣掉,也就是说虽然 li抢先一步买了票,但是zhang没有得到票,也没有扣掉钱。
这个就是redis对事务的支持,当然你可以设置多个监视值 watch key1 key2...只要这些key中有一个改动,那么事务是不会提交的。
最后取消监视:
127.0.0.1:6379> unwatch
OK
127.0.0.1:6379>