【Redis系列】Redis的事务处理

事务处理

redis对事务的支持目前还比较简单。redis 值能保证一个client 发起的事务中的命令可以连续的执行。而中间不会插入其他client的命令。当一个client在一个连接中发出multi命令时，这个连接会进入一个事务上下文，该连接后续的命令不会立即执行，而是先放到一个队列中，当执行exe命令时，reds会顺序的执行队列中的所有命令。

multi应用:

---

示例一：事务演示。

测试用例：输入multi命令，然后输入两条数据操作命令，最后执行。
结果，两条语句都执行成功。

分析：两条语句显示放到队列中，等exec语句之后，才开始执行。又由于redis是单线程，exec到队列里面执行过程不允许其他命令发过来，所以能保证其原子性。

示例二：事务执行两条语句，其中一条语法错误。事务回滚。

测试用例：首先multi.然后执行两条语句，分别是decrby zhao 100；sdaf（随便写的错误语句）
结果：

分析：当输入decrby zhao 100之后，将其放到队列中。等执行到sdaf ，检测发现该语句语法错误，故没有执行。

示例三:事务执行两条语句，其中一条语法没错，数据有问题。事务不能回滚。

sadd wang pig（sadd本来操作集合对象，在这用来操作set集合故出错）该语句执行时会报错。
结果：

分析：事务没有保证，当第二个语句有问题时，语句没有回滚，也没有撤销。

因此。单纯的应用multi 并不靠谱。它并不能在没有语法错误的情况下出现问题，保证事务的原子性。

Redis与 mysql事务比较：

方面	Mysql	Redis
开启	start transaction	muitl
语句	普通sql	普通命令
失败	rollback 回滚	discard 取消
成功	commit	exec

注①:
rollback与discard 的区别
如果已经成功执行了2条语句, 第3条语句出错.
Rollback后,前2条的语句影响消失.
Discard只是结束本次事务,前2条语句造成的影响仍然还在

注②:
在mutil后面的语句中, 语句出错可能有2种情况
1: 语法就有问题,
这种,exec时,报错, 所有语句得不到执行

2: 语法本身没错,但适用对象有问题. 比如 zadd 操作list对象
Exec之后,会执行正确的语句,并跳过有不适当的语句.

所以，又有了锁。

锁

乐观锁复杂事务控制：

---

watch 命令会见识给定的key,当exec时候，如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key。这样就可以对指定的key加乐观锁了。注意watch的key是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然了 exec，discard,unwatch命令都会清除连接中的所有监视。

举个列子：
我正在买票
Ticket -1 , money -100
而票只有1张, 如果在我multi之后,和exec之前, 票被别人买了—即ticket变成0了.
我该如何观察这种情景,并不再提交

悲观的想法:
世界充满危险,肯定有人和我抢, 给 ticket上锁, 只有我能操作. [悲观锁]
乐观的想法:
没有那么人和我抢,因此,我只需要注意,
有没有人更改ticket的值就可以了 [乐观锁]

  Redis的事务中,启用的是乐观锁,只负责监测key没有被改动.

例:
redis192.168.21.54:6379> watch ticket
OK
redis192.168.21.54:6379> multi
OK
redis192.168.21.54:6379> decr ticket
QUEUED
redis192.168.21.54:6379> decrby money 100
QUEUED//改命令执行后，在另一端将ticket减少了。
redis192.168.21.54:6379> exec
(nil) // 返回nil,说明监视的ticket已经改变了,事务就取消了.
redis192.168.21.54:6379> get ticket
“0”
redis192.168.21.54:6379> get money
“200”

Watch 监控的值发生了变化，就不去执行。
unwatch  取消所有watch监听

总结：

本文总结了redis的事务及乐观锁。以及通过watch怎样保证事务的原子性。