秋天，大雁南飞，草木枯荣，掉落下的依依不舍的树叶随着瑟瑟的秋风飞动。尽管田园一片荒凉，但金灿灿的干草已覆盖了整个大地，几颗松树笔直的立在大地上，天空是多么广阔，多么蔚蓝！地是多么浩瀚，多么无边！天和地连在了一起，已分不清地平线在哪里，秋天的原野拥抱着蓝天，广阔的蓝天拥抱着田野！
本文实例讲述了redis中的事务操作。分享给大家供大家参考，具体如下：
redis与mysql的事务
Redis支持简单的事务
简单使用
讲张三的100圆钱转账给lisi：
set zhangsan 800 set lisi 100 multi decrby zhangsan 100 incrby lisi 100 exec
失败的两种情况
在mutil后面的语句中, 语句出错可能有2种情况，还是以转账的情况来分析：
（1）语法就有问题
127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby zhang 100 QUEUED 127.0.0.1:6379> hasdfasdf (error) ERR unknown command 'hasdfasdf' 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 127.0.0.1:6379> mget zhang wang 1) "800" 2) "100"
这种,exec时,报错, 所有语句得不到执行，所以还是800和100圆
（2）语法本身没错,但适用对象有问题
127.0.0.1:6379> multi OK 127.0.0.1:6379> decrby zhang 100 QUEUED 127.0.0.1:6379> sadd wang 1 QUEUED 127.0.0.1:6379> exec 1) (integer) 700 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 127.0.0.1:6379> mget zhang wang 1) "700" 2) "100"
Exec之后,会执行正确的语句,并跳过有不适当的语句，所以这里是一个700圆一个100圆了
案例
假设买票案例，当前只有1张票和100块钱，如果我在买票的过程中，在我multi之后，和exec之前，票被别人买了—即ticket已经变成0了，然后我们执行exec的时候就会将票变为-1，这就不对了。
127.0.0.1:6379> set ticket 1 OK 127.0.0.1:6379> set money 100 OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> decr ticket QUEUED 127.0.0.1:6379> decrby money 10 QUEUED 127.0.0.1:6379> exec 1) (integer) -1 2) (integer) 90
使用watch来检测票有没有被买走
实用watch来检测指定的key，负责监测key没有被改动。
127.0.0.1:6379> set ticket 1 OK 127.0.0.1:6379> set money 100 OK 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 money 10 QUEUED 127.0.0.1:6379> exec (nil)//返回nil,说明监视的ticket已经改变了,事务就取消了. 127.0.0.1:6379> mget ticket money 1) "0" 2) "100"
在执行exec之前，票被买走了，ticket为0了，然后执行exec后，发现ticket被动了，所以就不执行事务了，事务被取消了。在执行exec的时候返回nil。
watch相关用法
watch key1 key2 ... keyN
作用：监听key1 key2..keyN有没有变化,如果有变, 则事务取消
unwatch
作用：取消所有watch监听
希望本文所述对大家Redis数据库程序设计有所帮助。
以上就是redis中的事务操作案例分析。万般努力，我只为出人头地。更多关于redis中的事务操作案例分析请关注haodaima.com其它相关文章！