目录
一、Redis 事务的核心定义
二、核心命令与执行流程
1. 核心命令（含阿里面试高频考点）
2. 执行流程实操（阿里面试常考场景：用户积分兑换）
三、Redis 事务的核心特性
1. 原子性：“部分满足”，非完全原子性
2. 隔离性：无隔离级别，“执行前可见，执行中不可插”
3. 持久性：无原生保证，依赖持久化策略
4. 无回滚机制
四、阿里业务中的实践场景与选型逻辑
1. 适用场景
2. 不适用场景（阿里面试高频追问）
3. 阿里优化实践
五、面试高频考点与应答话术
1. 考点 1：Redis 事务与 MySQL 事务的区别（必问）
2. 考点 2：Redis 事务的乐观锁（WATCH）原理
3. 考点 3：Redis 事务会阻塞其他命令吗？
Redis 事务是分布式场景中保障命令执行顺序与简单原子性的核心机制。
一、Redis 事务的核心定义
Redis 事务是将多个命令打包成队列，通过EXEC一次性、按顺序执行的机制，核心目标是避免命令执行过程中被其他客户端命令插队，同时提供基础的原子性保障（非完全原子性）。
与 MySQL 事务的本质区别：Redis 事务是 “命令级的批量执行”，不支持回滚、无隔离级别划分，仅解决 “顺序性” 和 “部分原子性” 问题；而 MySQL 事务是 “数据级的 ACID 保障”，聚焦数据一致性与故障恢复。
二、核心命令与执行流程
Redis 事务通过 4 个核心命令实现，执行流程固定为 “开启事务→命令入队→执行 / 放弃事务”，结合阿里常用的 “库存扣减” 场景实操：
1. 核心命令（含阿里面试高频考点）
| 命令 | 作用 |
|---|---|
MULTI | 标记一个事务块的开始。开启事务，进入 “事务模式”，后续命令暂不执行，仅加入队列 |
EXEC | 执行队列中所有命令，返回每个命令的执行结果（按入队顺序） |
DISCARD | 放弃事务，清空队列，退出事务模式 |
WATCH | 监视一个(或多个)key，如果在事务执行之前这个(或这些)key被其他命令所改动，那么事务将被打断 |
UNWATCH | 取消所有键的监控 |
2. 执行流程实操（阿里面试常考场景：用户积分兑换）
redis
# 1. 监控积分键（乐观锁：防止并发修改） 127.0.0.1:6379> WATCH user:1001:points # 监控用户1001的积分 OK # 2. 开启事务 127.0.0.1:6379> MULTI OK # 3. 命令入队（积分扣减50，兑换记录新增） 127.0.0.1:6379> DECRBY user:1001:points 50 QUEUED 127.0.0.1:6379> LPUSH user:1001:exchange "2024兑换优惠券" QUEUED # 4. 执行事务（若积分未被其他客户端修改，执行成功） 127.0.0.1:6379> EXEC 1) (integer) 150 # 积分扣减后结果 2) (integer) 3 # 兑换记录条数 # 异常场景：执行前积分被修改（如其他客户端执行INCRBY user:1001:points 10） 127.0.0.1:6379> EXEC (nil) # 事务取消，返回nil三、Redis 事务的核心特性
Redis 事务不支持完整 ACID，需精准理解其特性边界，阿里 P6 面试的核心考点：
1. 原子性：“部分满足”，非完全原子性
- 支持原子性的场景：命令入队时语法错误（如
SETT），Redis 会立即报错，EXEC执行时所有命令均不执行（符合原子性）。 - 不支持原子性的场景：运行时错误（如对字符串执行
INCR），Redis 会跳过错误命令，继续执行其他正确命令（不符合原子性）。
为什么 Redis 不支持完全原子性？
答：Redis 设计目标是高性能，回滚机制会增加复杂度；运行时错误多为开发者代码问题（如类型错误），应提前规避，而非依赖事务回滚。
2. 隔离性：无隔离级别，“执行前可见，执行中不可插”
- 执行前：
MULTI开启后、EXEC执行前，其他客户端修改的数据，事务执行时会读取最新值（无快照隔离，阿里业务中需用WATCH规避）。 - 执行中：
EXEC执行时，队列命令按顺序一次性执行，不会被其他客户端命令插队（保证顺序隔离）。
3. 持久性：无原生保证，依赖持久化策略
- 若 Redis 未开启持久化，事务执行后 Redis 崩溃，数据全部丢失。
- 开启
RDB：事务执行后未触发快照，崩溃则数据丢失；开启AOF：若为appendfsync everysec（阿里默认配置），可能丢失 1 秒内的事务数据。
详情请看我另外一篇文章：Redis的持久化机制（必须知道）
4. 无回滚机制
Redis 没有ROLLBACK命令，已执行的正确命令无法撤销，仅能通过业务层手动修复（如积分扣减失败后回补）。
四、阿里业务中的实践场景与选型逻辑
P6 面试需结合业务场景说明 Redis 事务的应用，以下是阿里常用场景：
1. 适用场景
- 批量操作命令：如一次性初始化多个缓存键（如用户基础信息），确保命令顺序执行，避免并发插入导致的数据混乱。
- 低并发 “读 - 改 - 写”：如普通商品库存扣减、用户积分更新（并发冲突概率低），通过
WATCH+ 事务实现乐观锁，避免超卖 / 超扣。 - 日志批量写入：如将用户操作日志批量写入 Redis 列表，保证日志顺序性，后续异步同步到数据库。
2. 不适用场景（阿里面试高频追问）
- 强原子性场景：如金融转账、订单支付（需完全原子性 + 回滚），阿里业务中会用 MySQL 事务 + 分布式锁实现。
- 高并发冲突场景：如秒杀活动（并发量 10W+），
WATCH会导致大量事务重试，阿里常用 “Redis 分布式锁（Redlock）+ Lua 脚本” 替代。 - 复杂事务逻辑：如跨键关联操作（如扣减库存同时修改订单状态），Redis 事务无法保证跨键原子性，需用分布式事务（如 TCC、SAGA）。
3. 阿里优化实践
- 结合 Lua 脚本：将事务命令封装为 Lua 脚本（如库存扣减 + 订单创建），利用 Lua 脚本的 “原子性执行” 特性，增强事务的原子性（Redis 会将 Lua 脚本视为单个命令执行）。
- 事务拆分：将大事务拆分为多个小事务，减少
EXEC执行时间，降低 Redis 阻塞风险（阿里 Redis 集群单命令执行超时阈值为 500ms）。 - 监控键精简：
WATCH仅监控必要的键（如仅监控库存键，不监控无关的订单键），减少事务取消概率。
五、面试高频考点与应答话术
1. 考点 1：Redis 事务与 MySQL 事务的区别（必问）
“两者核心差异体现在设计目标和 ACID 支持上：
①原子性：Redis 仅语法错误时保证原子性，MySQL 支持完全原子性（回滚）；
②隔离性：Redis 无隔离级别，MySQL 有 4 种隔离级别（默认 RR）；
③持久性：Redis 依赖持久化策略，MySQL 通过 redo/undo 日志保证持久性；
④回滚：Redis 无回滚，MySQL 支持ROLLBACK。业务选型上，阿里用 Redis 事务处理批量命令和低并发乐观锁场景，用 MySQL 事务处理核心数据一致性场景。”
2. 考点 2：Redis 事务的乐观锁（WATCH）原理
“WATCH基于乐观锁思想，核心是监控指定键的修改：
①WATCH执行时，Redis 会记录键的当前版本（基于 CRC16 校验）；
②MULTI入队命令后，EXEC执行前，若监控的键被其他客户端修改，版本号变化，Redis 会取消事务；
③事务执行成功或放弃后，WATCH自动取消。阿里业务中常用于低并发库存扣减，高并发场景会用分布式锁替代。”
3. 考点 3：Redis 事务会阻塞其他命令吗？
“会。EXEC执行时，Redis 会按顺序执行队列中的所有命令，期间会阻塞其他客户端的命令（Redis 是单线程模型）。因此阿里业务中会限制事务队列的命令数量（一般不超过 50 条），避免长时间阻塞 Redis，影响集群吞吐量。”
最后：
“Redis 事务是‘批量命令 + 乐观锁’的轻量级方案，核心价值是：保证命令顺序执行和低并发场景的数据一致性，但其不支持回滚、无完全原子性的特性，决定了它无法替代关系型数据库事务。Redis 事务常用于批量操作和低并发乐观锁场景，高并发、强一致性场景会结合分布式锁、Lua 脚本、分布式事务等方案互补。作为开发，需根据业务的一致性要求和并发量，选择合适的技术方案，而非盲目依赖 Redis 事务。
