Redis的事务、乐观锁和悲观锁

一、是什么

• 可以一次执行多个命令，本质是一组命令的集合。
• 一个事务中的所有命令都会序列化，按照顺序地串行化执行而不会被其他命令插入，不许加塞

二、能干嘛

• 一个队列中，一次性、顺序性、排他性的执行一系列命令

三、怎么玩

• Redis中开启事务的命令是：MULTI ，这个命令通常会回复一个OK【回复的是OK，但是这个事能不能办，什么时候办，办不办的成不知道】，用户将会一次性的打多个命令，而代替执行，按顺序执行，Redis将这些命令入队，所有的命令将会通过命令：EXEC 来被调用执行。
• 如果用命令：DISCARD 表示放弃丢弃，言下之意是放弃本次的批处理操作

• 常用命令：

  • DISCARD：取消事务，放弃执行事务块内的所有命令
  • EXEC：执行所有事务块内的命令
  • MULTI：标记一个事务块的开始
  • UNWATCH：取消 WATCH 命令对所有 key 的监控
  • WATCH  key [key . . . ]：件事一个（或多个）key，如果在事务执行之前这个（或这些）key被其他命令所改动，那么事务将被打断

• 正常执行：

  • 

• 放弃事务：

  • 

• 全体连坐：【在事务块中只要有一条命令执行是错的，那么整个事务块就不会执行】

  • 

• 冤头债主：【如果在事务块中所有命令都正确，但是结果会产生错误，那么冤有头债有主，谁错找谁】

  • 

• watch监控：

  • 悲观锁
    •  悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，当其他线程想要访问数据时，都需要阻塞挂起。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁、表锁，读锁，写锁等，都是在操作之前先上锁。
    • 在Java中，synchronized的思想也是悲观锁。​​​​​​​
  • 乐观锁：【冲突检测和数据更新】
    • ​​​​​​​乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候回判断一下再次期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
    • 乐观锁策略：提交版本必须大于记录当前版本才能执行更新
    • 一般会使用版本号机制或CAS操作实现：
      • version方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

      • 核心SQL代码：

        update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

  • ​​​​​​​​​​​​​​​​​​​​​CAS（Check And Set【先检查再动手设置】）
    • ​​​​​​​CAS操作方式：即 compare and set，CAS是乐观锁技术，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

  • ********************************************************************

  • *无加塞篡改，先监控再开启 MULTI ，保证两笔金额变动在同一个事务内*

  • ********************************************************************

  • 如下图：就模拟了一个购物的过程，在买的过程中，别人会给你打钱，当你要完成支付的时候报错了
  • 
  • 解决：【使用 UNWATCH 取消对当前 key 的监控，之后再一次进行监控（得到最新的数据），直到成功为止】
  • 

  • 注意：

  • **********************************************

  • 一旦执行了 EXEC，之前加的监控所都会被取消掉*

  • **********************************************

四、小结

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

五、三阶段

• 开启：以 MULTI 开始一个事务
• 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
• 执行：由 EXEC 命令触发事务

六、三特性

• 单独的隔离操作：事务中所有的命令多会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际的执行，也就是不存在 “ 事务内的查询要看到事务里面的更新，在事务外查询不能看到 ” 这个是让人万分头痛的问题
• 不保证原子性：Redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚