noSQL-redis学习（五） -- redis事务

Redis的事务

什么是事务？

       可以一次执行多个命令，本质是一组命令的集合。一个事务中的

所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。 由于redis是单线程来处理所有client的请求的所以做到这点是很容易的。一般情况下redis在接受到一个client发来的命令后会立即处理并 返回处理结果，但是当一个client在一个连接中发出multi命令有，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一 个队列中。当从此连接受到exec命令后，redis会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给client.然后此连接就 结束事务上下文。

 

Redis事务的实现需要用到 MULTI 和 EXEC 两个命令，事务开始的时候先向Redis服务器发送 MULTI 命令，然后依次发送需要在本次事务中处理的命令，最后再发送 EXEC 命令表示事务命令结束。

 

举个例子

case1：正常执行

  

从输出中可以看到，当输入MULTI命令后，服务器返回OK表示事务开始成功，然后依次输入需要在本次事务中执行的所有命令，每次输入一个命令服务器并不会马上执行，而是返回”QUEUED”，这表示命令已经被服务器接受并且暂时保存起来，最后输入EXEC命令后，本次事务中的所有命令才会被依次执行，可以看到最后服务器一次性返回了三个OK，这里返回的结果与发送的命令是按顺序一一对应的，这说明这次事务中的命令全都执行成功了。

Case2：全体连坐

当事务开始的时候，如果有错误的命令  如 没有发现的命令 出错

即使后面的命令也全是对的，也不执行操作， 抛出错误

EXECABORT Transaction discarded because of previous errors.

Case3：冤头债主

此时看到即使EXC执行之后，报错，其他两个还是会执行。

Case4：watch监控

悲观锁/乐观锁/CAS(Check And Set)

乐观并发控制(乐观锁)和悲观并发控制（悲观锁）是并发控制主要采用的技术手段

无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。其实不仅仅是关系型数据库系统中有乐观锁

和悲观锁的概念，像memcache、hibernate、tair等都有类似的概念。

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）

修改持保守态度(悲观)，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库

提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了

加锁机制，也无法保证外部系统不会修改数据）

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的

时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳

WATCH  命令可以为 Redis 事务提供 check-and-set （CAS）行为

被WATCH 的键会被监视，并会发觉这些键是否被改动过了。如果有至少一个被监视的键在EXEC 执行之前被修改了，那么整个事务都会被取消

此时可以看到，当我WATCH k6 的时候，开启事务，set k6 v7 入队，在开启另一个终端，set k6 v8 执行，

之后返回第一个窗口 执行事务exec 返回的是nil 此时get k6 的值是v8 说明事务是没有执行的

如果有WATCH一些key值 可以通过UNWATCH来取消对这些key的监控