Redis事务

模拟一个买票的场景：现在只剩一张票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>