redis mysql事务处理_redis中的事务操作案例分析

本文实例讲述了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数据库程序设计有所帮助。