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.常用命令
    参考链接之一:http://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 命令没有错误，能够将命令加入队列。
      

    • 放弃事务
      在开启事务，且命令入队了以后需要取消或者放弃事务。(常用于业务逻辑中)。
      

    • 全体连坐
      开启事务，当队列中出现命令执行错误时，Redis将放弃整个事务。示例如下：
      

    • 冤头债主
      开启事务，队列中无命令错误，在执行Redis Txn.出现错误，此时无法执行成功的命令将会回滚，其他的命令依旧执行，如下图所示。
      

      • 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同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。