Redis Exec 命令（快速上手）

Redis Exec 命令：掌握事务执行的底层逻辑

在日常开发中，我们常常需要保证一组操作的原子性——要么全部成功，要么全部失败。尤其是在高并发场景下，比如账户转账、库存扣减等，一个操作的完整性至关重要。Redis 为此提供了事务机制，而 EXEC 命令正是这个机制的“启动按钮”。今天，我们就来深入理解 Redis 中的 EXEC 命令，从它的工作原理到实际应用场景，带你彻底掌握这个核心操作。

什么是 Redis 事务？为何需要 EXEC？

在传统数据库中，事务（Transaction）是保证数据一致性的基石。Redis 虽然是内存数据库，但也支持一种轻量级的事务机制，它通过 MULTI、EXEC 和 DISCARD 三个命令来实现。

简单来说，当你使用 MULTI 命令时，Redis 会进入事务模式。之后发送的所有命令都会被暂时缓存起来，不会立即执行。直到你调用 EXEC 命令，Redis 才会一次性执行所有缓存的命令。

这个过程就像你去餐厅点餐：

  • 你先说“我要点菜”（MULTI）
  • 然后一口气把所有想吃的菜都报出来（发送多个命令）
  • 最后说“上菜！”（EXEC）——这时厨房才开始统一准备

区别于传统数据库的事务，Redis 的事务不支持回滚（rollback），但保证了命令的“顺序执行”和“原子性”——即要么全部执行，要么一个都不执行（如果中间出现错误，已执行的命令不会撤销）。

EXEC 命令的语法与基本使用

EXEC 命令的语法非常简单：

EXEC

它没有参数，只需在 MULTI 模式下调用即可。返回值是一个数组，包含每个命令的执行结果。

实际示例：使用 EXEC 完成一次事务操作

MULTI

SET a 1

SET b 2

GET a

EXEC

执行结果如下：

1) OK
2) OK
3) "1"

说明：

  • MULTI 后，Redis 返回 QUEUED 表示命令已排队
  • EXEC 执行后，返回一个数组，对应每个命令的执行结果
  • 三个命令都成功执行，且按顺序完成

EXEC 与 WATCH：防止并发冲突

在高并发环境下，如果多个客户端同时操作同一个键，可能会导致数据不一致。比如两个用户同时读取库存，都发现还有 10 个，然后各自扣减 1，结果库存变成了 8，而不是 9。

Redis 提供了 WATCH 命令来解决这个问题。它允许你在事务开始前“监视”一个或多个键。如果在事务执行期间，这些键被其他客户端修改过，EXEC 就会返回空，表示事务被取消。

实际案例：库存扣减事务

WATCH stock

MULTI

GET stock

DECR stock

EXEC

关键点：

  • 如果在 EXEC 执行前，另一个客户端修改了 stock 键，那么 EXEC 会返回 nil，表示事务失败
  • 你可以捕获这个结果，然后重试事务，直到成功

这种机制类似于“乐观锁”：先假设没人修改，如果真有人改了，就放弃本次操作，重新来过。

EXEC 命令的返回值详解

EXEC 的返回值是一个数组，每个元素对应一个命令的执行结果。理解这个返回值结构，对调试和业务逻辑设计非常重要。

返回值类型分析

返回类型 说明 示例
OK 命令成功执行 SET key value 返回 OK
nil 无返回值或键不存在 GET non_existent_key 返回 nil
数组 多个命令结果的集合 EXEC 返回 [OK, OK, "1"]
nil（事务失败） 因 WATCH 冲突导致事务被取消 EXEC 返回 nil

示例：查看 EXEC 返回的数组结构

MULTI
SET user:1001 "Alice"
INCR user:login_count
GET user:1001
EXEC

返回：

1) OK
2) (integer) 1
3) "Alice"

解读：

  • 第一个命令 SET 返回 OK
  • 第二个 INCR 返回整数 1（表示自增后结果）
  • 第三个 GET 返回字符串 "Alice"
  • 整体以数组形式返回，便于程序解析

EXEC 与错误处理：理解“部分执行”现象

Redis 事务的一个重要特性是：它不支持回滚。这意味着如果事务中某个命令出错，Redis 仍会继续执行后续命令。

举例：命令语法错误导致事务部分执行

MULTI
SET key1 "value1"
INCR key2    # key2 不存在，且不是数字，INCR 会报错
GET key1
EXEC

执行结果：

1) OK
2) (error) ERR value is not an integer or out of range
3) "value1"

重点：

  • SET key1 "value1" 成功执行
  • INCR key2 因类型错误失败，但不影响后续 GET key1
  • Redis 会继续执行事务中剩下的命令

这说明：Redis 事务是“部分执行”而非“全部失败”。因此，在设计事务逻辑时，必须考虑错误处理，不能依赖事务自动回滚。

实战场景：用户注册流程的事务实现

我们来模拟一个用户注册流程，需要完成以下操作：

  1. 生成用户 ID（使用 INCR）
  2. 存储用户名（SET）
  3. 记录注册时间（SET）

这些操作必须原子完成，否则可能出现用户 ID 重复或数据不一致。

完整代码示例

MULTI

INCR user:next_id

SET user:1001:name "Bob"

SET user:1001:register_time "1712345678"

EXEC

返回结果：

1) (integer) 1001
2) OK
3) OK

说明：

  • INCR 返回自增后的 ID，即 1001
  • 两个 SET 返回 OK
  • 三步操作在 EXEC 触发后一次性完成，避免了并发问题

总结：Redis Exec 命令的核心价值

Redis Exec 命令 是 Redis 事务机制的执行核心。它将多个命令打包执行，确保操作的顺序性和原子性。虽然它没有传统数据库的“回滚”功能，但通过 WATCH 机制，我们可以在高并发场景下实现“乐观锁”式的控制。

掌握 EXEC，意味着你掌握了 Redis 中“批量操作”的正确姿势。无论是在缓存更新、订单处理，还是用户状态管理中，合理使用事务都能显著提升系统可靠性。

最后提醒：

  • 使用 MULTI 和 EXEC 时，注意命令的幂等性
  • 对于关键操作，建议结合 WATCH 使用
  • 不要依赖事务自动回滚，错误处理必须显式编写

当你在项目中遇到需要“一组操作要么全成功，要么全失败”的场景时，不妨回想一下：Redis 的 EXEC 命令，或许就是你最合适的解决方案。