Redis 事务机制
文章目录
- 一、什么是事务？
- 二、事务相关操作
- 总体认识
- 基本操作流程
- watch 操作演示
- watch 原理
一、什么是事务？
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 的值的变化，防止数据不一致问题。这条命令后面专门讲。
基本操作流程
- 开启事务，执行基本的命令。
- 此时，我们可以新开一个客户端查看一下 key1 key2 ，此时key1 key2 仍然为空。
- 执行 exec 命令，逐条得到事务中命令的返回值
- 之后进行查询就能看到值了
discard 操作：
watch 操作演示
问题场景：
- 客户端 1 开启事务，执行 set k1 111。
- 在客户端 1 执行 exec 之前，客户端 2 执行 set k1 222
- 客户端1 执行 exec
问，此时的 k1 的值？
答案是：111。这是因为set k1 111 实际在 exec 命令之后才会执行，会覆盖客户端2 执行的set k1 222，所以最终的值是 111。
场景示例：
- 客户端 1 开启事务，执行 set k1 111。
- 在客户端 1 执行 exec 之前，客户端 2 执行 set k1 222
- 客户端1 执行 exec，查看 k1 的值
这样就会存在一定的歧义，引入 watch 操作，就能避免上述问题：
WATCH key1 [key2 key3 ...]
原理：
- 当开启事务的时候, 如果对 watch 的 key 进⾏修改, 就会记录当前 key 的 “版本号”. (版本号是个简单的整数, 每次修改都会使版本变⼤. 服务器来维护每个 key 的版本号情况)
- 在真正提交事务的时候, 如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号, 就会让事务执⾏失败. (事务中的所有操作都不执⾏).
演示：
- 删除 k1 防止之前值的干扰，客户端1 先watch k1 再开启事务，执行 set k1 111。
- 客户端 2 执行 set k1 222
- 客户端1 执行 exec ，再查看 k1 的值
watch 原理
Redis 的 WATCH 命令是实现乐观锁的核心机制，用于在事务执行前监控指定的键，确保事务执行的原子性和一致性。其底层原理可以总结为以下几个关键点：
-
版本号机制
- Redis 为每个键（key）维护一个版本号（本质是一个整数计数器）。
- 每当键被修改（无论是通过
SET、INCR等命令），其版本号会自动加 1。 - 版本号由 Redis 服务器在底层自动管理，用户无需手动干预
-
监控键的版本快照
- 当执行
WATCH key1 [key2 ...]时，Redis 会记录当前被监控键的最新版本号，形成一个“版本快照”。
- 当执行
-
事务执行的版本校验
- 执行 WATCH 后，用户通过
MULTI开启事务，然后编写一系列命令（如SET、HSET 等）。 - 当通过 EXEC 提交事务时，Redis 会做一次版本校验：
- 检查所有被 WATCH 的键，当前服务器上的版本号是否与 WATCH 时记录的“版本快照”一致。
- 如果全部一致：说明事务期间没有其他客户端修改这些键，事务正常执行，所有命令生效。
- 如果有任何一个键的版本号不一致：说明该键被其他客户端修改过，事务整体取消（所有命令都不执行），
EXEC返回nil表示事务失败。
- 执行 WATCH 后，用户通过
-
乐观锁的体现
WATCH的设计基于“乐观锁”思想：默认认为事务执行期间不会有并发修改，因此不主动加锁阻塞其他操作。- 只有在提交时通过版本号比对发现冲突，才放弃执行，避免了悲观锁的性能开销。