笔记整理自【尚硅谷】Redis 6 入门到精通 超详细 教程

Redis——事务与锁机制

1. Redis的事务定义

• Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 注意：Redis 的事务与 MySQL 的事务不同
  • Redis 事务的主要作用就是串联多个命令防止别的命令插队。

2. 事务基本命令 (Multi、Exec、Discard)

从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。

组队的过程中可以通过 Discard 来放弃组队。

案例

• 组队成功，提交成功

  

• 放弃组队

  

• 组队中有命令错误，所有命令都不会执行

  

• 组队中不报错，执行时报错（只有错误的命令没有执行）

  

3. 事务的错误处理

发生错误的时机有两种情况：

• 组队阶段出错

  • 组队中某个命令出现了报告错误，执行时 整个队列的任务都会被取消。

  

• 执行阶段出错

  • 如果执行阶段某个命令报出了错误，则 只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

  

4. Redis事务三特性

• 单独的隔离操作
  • 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念
  • 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
• 不保证原子性
  • 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

5. 事务冲突的问题

为什么要做成事务？

想想一个场景：有很多人有你的账户，同时去参加双十一抢购。

Ⅰ. 例子

• 一个请求想给金额减 800080008000
• 一个请求想给金额减 500050005000
• 一个请求想给金额减 100010001000

如果三个请求进来并发的执行可能会产生冲突问题，最极端的如下图这种情况：

没有加事务，互相产生影响。

解决方式使用加锁的方式：

• 悲观锁
• 乐观锁

Ⅱ. 悲观锁

• 悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。

• 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
  • 在 Java 中，synchronized 从偏向锁、轻量级锁到重量级锁，全是悲观锁。JDK 提供的 Lock 实现类全是悲观锁。

效率低，只能一个人一个人进行操作，不能多人同时进行。

Ⅲ. 乐观锁

• 乐观锁（Optimistic Lock），顾名思义，就是很乐观，即每次去拿数据的时候都认为其他线程不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间有没有其他线程去更新这个数据，可以使用版本号等机制。
• 乐观锁适用于多读的应用类型，这样可以提高吞吐量。
• Redis 就是利用这种 check-and-set 机制实现事务的。

Ⅳ. WATCH

• 在执行 multi 之前，先执行 watch key [key...]，可以监视一个（或多个）key 。

• 如果在事务执行之前这个 key 被其他命令所改动，那么事务将被打断。

  • 测试

    • 进程1监控balance，并进行修改操作：

    

    • 进程2也监控balance，进行修改操作，事务被打断：

    

  • 这是一个乐观锁的过程，进程1先执行，把balance的版本号进行修改，而进程2再执行时 判断发现版本号不一样，取消操作。

Ⅴ. UNWATCH

• 取消 WATCH 命令对所有 key 的监视。
• 如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行，那么就不需要再执行 UNWATCH 。

补充：通过WATCH命令可以实现乐观锁的功能，无法实现悲观锁操作。

但是可以通过编写LUA脚本，让Redis加载脚本，从而实现悲观锁。