Redis 讲解系列之 Redis的事务-蒲公英云

Redis 讲解系列之 Redis的事务

概念

作为一个应用场景为缓存的Nosql，Redis 包含了事务的概念，可实际上Redis提供的事务不论从概念和实现程度上而言与一些 RDBMS 如Oracle、Mysql(Default as Innor DB Engine)的事务有着概念部分交叉，实现程度截然不同的区别。下面我们就来看看Redis的事务。

RDBMS Transaction(传统关系型数据库的事务)

传统关系型数据一般包含事务特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

原子性（Atomicity）
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性（Consistency）
指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。
隔离性（Isolation，又称独立性）
指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。(关于事务的隔离级别我们将在Mysql 高级本分详细讲解)。
持久性（Durability）
指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

Redis Transaction

Redis Txn. 是什么？
- 可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞。
Redis Txn. 能干嘛？
- 一个队列中，一次性、顺序性、排他性的执行一系列命令。
Redis Txn. Core Conception.
- Redis Txn.常用命令
  参考链接之一//www.runoob.com/redis/redis-transactions.html
  - MULTI

         *  标记一个事务块的开始。
     *  EXEC  
         *  执行所有事务块内的命令。
     *  DISCARD  
         *  取消事务，放弃执行事务块内的所有命令。
     *  WATCH key \[key …\]  
         *  监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
     *  UNWATCH  
         *  取消 WATCH 命令对所有 key 的监视。
 *  Redis Txn. 常遇到的4种Case。  
    下面我总结一下我们在使用Redis时常遇到的几种情况。
     *  正常执行  
        正常使用Redisa Txn.即Redis 命令没有错误，能够将命令加入队列。  
        ![这里写图片描述][SouthEast]
     *  放弃事务  
        在开启事务，且命令入队了以后需要取消或者放弃事务。(常用于业务逻辑中)。  
        ![这里写图片描述][SouthEast 1]
     *  全体连坐  
        开启事务，当队列中出现命令执行错误时，Redis将放弃整个事务。示例如下：  
        ![这里写图片描述][SouthEast 2]
     *  冤头债主  
        开启事务，队列中无命令错误，在执行Redis Txn.出现错误，此时无法执行成功的命令将会回滚，其他的命令依旧执行，如下图所示。  
        ![这里写图片描述][SouthEast 3]
         *  Watch 监控(Redis的‘锁’的概念)
         *  在传统的RDBMS 中有表锁行锁的概念，已Mysql 两种 Engie为例子：
             *  MyISM：表所，不支持高并发，不支持事务…
             *  Innor DB：行锁，支持高并发，支持事务….
         *  Redis 的 Watch  
            WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值）。
     *  悲观锁/乐观锁/CAS(Check And Set)
         *  悲观锁  
             *  悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
         *  乐观锁
             *  乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，乐观锁策略:提交版本必须大于记录当前版本才能执行更新。
         *  CAS
             *  CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。  
                CAS顶多算是乐观锁写那一步操作的一种实现方式罢了，不用CAS自己加锁也是可以的。

Redis Watch 执行过程以及例子
- 以初始化信用卡可用余额和欠额为例子
- 无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
- 有加塞篡改，监控了key，如果key被修改了，后面一个事务的执行失效
- unwatch
- 一旦执行了exec之前加的监控锁都会被取消掉了
- Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行。
- 例子
- 小结

     *  通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

Redis Txn. 的三个阶段
- 开启：以MULTI开始一个事务。
- 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面。
- 执行：由EXEC命令触发事务。
Redis Txn. 的三个特性
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
- 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。