redis--事务处理与乐观锁

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

127.0.0.1:6379> get age
"30"
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set age 10
QUEUED
127.0.0.1:6379> set age 20
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
127.0.0.1:6379> get age
"20"

如何取消一个事务

discard命令其实就是清空事务的命令队列并退出事务上下文，也就是我们常说的事务回滚。

注：在mysql中，如果一个事务队列中的一条语句发生错误，事务会回滚，而在redis中，则不会回滚。

127.0.0.1:6379> get name
"ysy"
127.0.0.1:6379> get age
"20"
127.0.0.1:6379> incr name
(error) ERR value is not an integer or out of range
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> incr name
QUEUED
127.0.0.1:6379> exec
1) (integer) 21
2) (error) ERR value is not an integer or out of range
127.0.0.1:6379> get age
"21"
127.0.0.1:6379> get name
"ysy"

从这个例子可以看到，age由于是个数字，那么他可以有自增运算，但是name是个字符串，无法对其进行自增运算，所以会报错，如果按传统关系型数据库的思路来讲，整个事务都会回滚，但是我们看到redis却是将可以执行的命令提交了，所以这个现象对于习惯于关系型数据库的操作的朋友来说是很别扭的，这一点也是redis今天需要改进的地方。

乐观锁

大多数是基于数据版本（version）的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个”version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。此时，将提交数据的版本号与数据库表对应记录的当前版本号进行比对，如果提交的数据版本号大于数据库当前版本号，则予以更新，否则认为是过期数据。

redis乐观锁实例

假设有一个age的key，我们开2个session来对age进行赋值操作，我们来看一下结果如何

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