Redis 事务机制

一、什么是事务？

Redis 的事务和 MySQL 的事务概念上是类似的. 都是把⼀系列操作绑定成⼀组. 让这⼀组能够批量执⾏.
Redis 的事务和 MySQL 事务的区别：

• 弱化的原⼦性: redis 没有 “回滚机制”. 只能做到这些操作 “批量执⾏”. 不能做到 “⼀个失败就恢复到初始状态”.
• 不保证⼀致性: 不涉及 “约束”. 也没有回滚. MySQL 的⼀致性体现的是运⾏事务前和运⾏后结果都是合理有效的, 不会出现中间⾮法状态.
• 不需要隔离性: 也没有隔离级别, 因为不会并发执⾏事务 (redis 单线程处理请求) .
• 不需要持久性: 是保存在内存的. 是否开启持久化, 是redis-server ⾃⼰的事情, 和事务⽆关.

关于 Redis 事务原子性的争议
争议点主要在于 原子性 的定义到底是把命令打包一起执行即可还是在此基础上必须具备 MySQL事务的回滚机制

Redis 事务理解
Redis 事务本质上是把一系列命令插入到 “事务队列中”。每次客户端在事务中进⾏⼀个操作, 都会把命令先发给服务器, 放到 “事务队列” 中（但是并不会立即执行）。等遇到 EXEC 命令之后，才会按照队列顺序依次执行命令。

Redis 事务的使用场景
秒杀（抢票）

在抢票场景中需要注意的是 “超卖” 问题。就比如我最多只能 500 张票，但我的买票系统让 501 个人都买到票了，这就是“超卖”问题。这种问题是由于线程竞争资源导致的。传统的解决方式是加锁，这里介绍通过 Redis 事务解决方案。

使用 redis 事务机制的话，就可以把 获取票数、判断 票数大于 0和票数减一 这三个操作打包成一个事务，再加上 Redis 服务器本身是 单线程模型，这样就可以保证不会出现竞争资源导致的超卖问题。

二、事务相关操作

总体认识

事务的核心操作就是 MULTI（开启事务）、EXEC（真正执行事务）、DISCARD（放弃事务）、WATCH（监控 key 的变化）

• MULTI : 开启一个事务，执行成功返回 OK
• EXEC: 执行这条命令后，将真正执行 “事务队列” 中存放的命令
• DISCARD: 放弃当前事务，即服务器收到这条命令就会清空队列。之前的操作都不会执行。
• WATCH : 监控某个 key 的值的变化，防止数据不一致问题。这条命令后面专门讲。

基本操作流程

1. 开启事务，执行基本的命令。
   
2. 此时，我们可以新开一个客户端查看一下 key1 key2 ，此时key1 key2 仍然为空。
   
3. 执行 exec 命令，逐条得到事务中命令的返回值
   
4. 之后进行查询就能看到值了
   

discard 操作：

watch 操作演示

问题场景：

1. 客户端 1 开启事务，执行 set k1 111。
2. 在客户端 1 执行 exec 之前，客户端 2 执行 set k1 222
3. 客户端1 执行 exec

问，此时的 k1 的值？
答案是：111。这是因为set k1 111 实际在 exec 命令之后才会执行，会覆盖客户端2 执行的set k1 222，所以最终的值是 111。

场景示例：

• 客户端 1 开启事务，执行 set k1 111。
  
• 在客户端 1 执行 exec 之前，客户端 2 执行 set k1 222
  

3. 客户端1 执行 exec，查看 k1 的值
   

这样就会存在一定的歧义，引入 watch 操作，就能避免上述问题：

WATCH key1 [key2 key3 ...]

原理：

• 当开启事务的时候, 如果对 watch 的 key 进⾏修改, 就会记录当前 key 的 “版本号”. (版本号是个简单的整数, 每次修改都会使版本变⼤. 服务器来维护每个 key 的版本号情况)
• 在真正提交事务的时候, 如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号, 就会让事务执⾏失败. (事务中的所有操作都不执⾏).

演示：

1. 删除 k1 防止之前值的干扰，客户端1 先watch k1 再开启事务，执行 set k1 111。
   
2. 客户端 2 执行 set k1 222
   
3. 客户端1 执行 exec ，再查看 k1 的值
   

watch 原理

Redis 的 WATCH 命令是实现乐观锁的核心机制，用于在事务执行前监控指定的键，确保事务执行的原子性和一致性。其底层原理可以总结为以下几个关键点：

1. 版本号机制

   • Redis 为每个键（key）维护一个版本号（本质是一个整数计数器）。
   • 每当键被修改（无论是通过 SET、INCR 等命令），其版本号会自动加 1。
   • 版本号由 Redis 服务器在底层自动管理，用户无需手动干预

2. 监控键的版本快照

   • 当执行 WATCH key1 [key2 ...] 时，Redis 会记录当前被监控键的最新版本号，形成一个“版本快照”。

3. 事务执行的版本校验

   • 执行 WATCH 后，用户通过 MULTI 开启事务，然后编写一系列命令（如 SET、HSET 等）。
   • 当通过 EXEC 提交事务时，Redis 会做一次版本校验：
   • 检查所有被 WATCH 的键，当前服务器上的版本号是否与 WATCH 时记录的“版本快照”一致。
     • 如果全部一致：说明事务期间没有其他客户端修改这些键，事务正常执行，所有命令生效。
     • 如果有任何一个键的版本号不一致：说明该键被其他客户端修改过，事务整体取消（所有命令都不执行），EXEC 返回 nil 表示事务失败。

4. 乐观锁的体现

   • WATCH 的设计基于“乐观锁”思想：默认认为事务执行期间不会有并发修改，因此不主动加锁阻塞其他操作。
   • 只有在提交时通过版本号比对发现冲突，才放弃执行，避免了悲观锁的性能开销。