网站Logo 拾荒的小海螺
首页
研想花开
生活随笔
图库
茶杯狐
关于

Redis：事务能否保证原子性

admin
3
2025-07-23

1、简述

在日常开发中，Redis 被广泛用作缓存、中间件乃至某些场景下的主存数据库。和关系型数据库不同，Redis 提供了一种轻量级的事务机制，它的核心是 MULTI / EXEC 命令组。许多开发者初识 Redis 事务时，会有一个重要疑问：

Redis 的事务能否保证原子性？

本文将深入剖析 Redis 事务的设计原理，解释其原子性表现在哪些方面，以及在哪些情况下它不能提供我们传统意义上的事务保障。

image-i1k1.png

2、什么是 Redis 事务？

Redis 的事务包括三个基本命令：

  1. MULTI：开启事务。
  2. EXEC：执行事务块中所有命令。
  3. DISCARD：放弃事务。

Redis 会在 MULTI 命令之后，将随后发送的命令入队缓存，直到 EXEC 被调用。执行时，这些命令会 依次、按顺序地执行。

3、原子性表现

Redis 所谓的“事务原子性”，其定义与传统数据库不同，它具有以下特点：

✅ 一次性、顺序执行（命令级原子）

当你执行 EXEC 时，Redis 会将所有缓存的命令 一次性执行完毕，中间不会插入其他客户端的命令。也就是说，从 EXEC 到所有命令完成执行的这段时间里，是一个逻辑上的原子块。

❌ 不支持回滚

一旦执行 EXEC，即使其中一个命令出错，也不会回滚之前成功执行的命令。例如：

MULTI
SET key1 "value1"
INCR key1      # 错误：value1 不是整数
SET key2 "value2"
EXEC

上述事务中，INCR key1 会因类型错误失败，但 SET key1 和 SET key2 仍然会执行，key2 也会被设置成功。

也就是说，Redis 的事务是一种“尽力而为”的事务，不能提供传统意义上的“全或无”原子性。

4、为什么 Redis 不支持真正的原子事务？

Redis 的核心目标是性能与简单性。支持真正的原子事务需要增加复杂的回滚机制和锁机制，这会显著降低 Redis 的执行效率。此外，Redis 是单线程模型，已经天然地避免了并发写入冲突，因此只实现了“串行执行”语义的事务。

Redis 中的回滚行为取决于错误发生的阶段，即：

  • 语法/命令格式错误（发生在入队阶段）
  • 运行期错误（发生在执行阶段）

这两种错误在 Redis 事务（MULTI / EXEC）中有非常关键的区别，下面我们来详细解析这一点，并更新博客内容以更准确地描述 Redis 的事务回滚机制。在 Redis 的事务处理机制中，命令错误可分为两大类：

4.1 语法错误（入队阶段） → 导致整个事务失败

在 MULTI 和 EXEC 之间，如果某条命令语法上就有问题（如参数数量错误、命令名拼写错误），Redis 会立刻返回错误，不会进入队列。此时整个事务标记为“脏”，EXEC 执行时会直接失败，所有命令都不会被执行。

示例：

MULTI
SET key1 "value1"
INCR           # 缺少参数，语法错误
SET key2 "value2"
EXEC           # 返回 error，整个事务不执行

Redis 响应：

(error) ERR wrong number of arguments for 'incr' command

结论：语法错误在入队阶段即被检测，事务被标记为失败，EXEC 会拒绝执行，无需回滚。

4.2 运行时错误（执行阶段） → 不会回滚前面已成功命令

如果所有命令语法正确，在 MULTI 之后成功入队，但在 EXEC 执行过程中出现错误（比如类型错误、键不存在、算术错误等），那么：

  • 出错命令本身失败
  • 其它命令继续执行
  • 已执行命令不会回滚

示例：

SET key1 "hello"
MULTI
SET key2 "world"
INCR key1      # 错误：key1 是 string，不是整数
SET key3 "!"
EXEC

Redis 响应（伪代码）：

1) OK
2) (error) ERR value is not an integer
3) OK

结论：运行时错误不会阻止事务整体执行，也不会影响其他命令执行；已生效的命令不会被回滚。

✅ 实战总结：如何区分并应对这两类错误？

错误类型 发生阶段 事务是否执行 是否回滚 建议处理
语法/格式错误 入队阶段 ❌ 不执行 ❌ 不需要回滚（直接失败） 开发阶段就应避免
执行时错误 执行阶段 ✅ 部分执行 ❌ 不支持回滚 建议使用 Lua 或 WATCH 检查

🚨 回滚行为：语法错误 vs 执行期错误

Redis 的事务回滚并非传统意义上的“回滚”，其行为取决于错误发生的阶段：

  • 命令入队失败（语法错误）：事务标记为失败，EXEC 不会执行任何命令。
  • 命令执行失败（运行期错误）：出错命令失败，其他命令仍然执行，已执行命令不可回滚。

因此，在使用 Redis 事务时，应注意提前验证命令的合法性，并考虑使用 Lua 脚本或乐观锁（WATCH）来增强数据一致性。

5、Redis 保证事务原子性的方式

虽然 Redis 事务本身不支持完全的原子性，但你可以借助其他机制来提高数据一致性保障：

5.1 使用 Lua 脚本（推荐）

Lua 脚本在 Redis 中的执行是原子性的。Redis 会将整个脚本作为一个命令来执行，期间不会被其他客户端中断。

示例：

EVAL "redis.call('SET', KEYS[1], ARGV[1]); redis.call('INCR', KEYS[2])" 2 key1 key2 "value1"

无论脚本执行过程中出现什么问题，都不会被其他客户端干扰。下面我将列举几种常见的 Lua 实战案例，展示如何用 Redis + Lua 保证操作原子性：

📌 示例 1：原子性扣减库存（防止超卖）

业务场景：商品秒杀，每个用户限购一件，库存不能为负数。

-- KEYS[1] = stock_key
-- ARGV[1] = 扣减数量，通常为 "1"

local stock = tonumber(redis.call("GET", KEYS[1]))
local num = tonumber(ARGV[1])

if stock >= num then
    redis.call("DECRBY", KEYS[1], num)
    return 1  -- 成功
else
    return 0  -- 库存不足
end

调用方式：

EVAL "<上面脚本>" 1 item_stock 1

📌 示例 2：分布式锁（设置 + 过期 +判定原子化）

业务场景：原子性地设置一个分布式锁，并设置过期时间，避免 SET + EXPIRE 之间被中断。

-- KEYS[1] = lock key
-- ARGV[1] = lock value (随机 UUID)
-- ARGV[2] = expiration time in seconds

if redis.call("SETNX", KEYS[1], ARGV[1]) == 1 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[2]))
    return 1  -- 成功加锁
else
    return 0  -- 已被锁住
end

📌 示例 3：安全释放分布式锁（比对标识值）

业务场景：防止误删别人加的锁。

-- KEYS[1] = lock key
-- ARGV[1] = lock value (加锁时使用的 UUID)

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

📌 示例 4：原子性计数 + 封禁（限流）

业务场景：用户每分钟最多访问 100 次，超限则阻止并封禁。

-- KEYS[1] = user:request:count:{uid}
-- KEYS[2] = user:block:{uid}
-- ARGV[1] = 请求上限（如 100）
-- ARGV[2] = 计数过期时间（如 60 秒）
-- ARGV[3] = 封禁时间（如 300 秒）

local current = redis.call("INCR", KEYS[1])
if current == 1 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[2]))
end

if current > tonumber(ARGV[1]) then
    redis.call("SETEX", KEYS[2], tonumber(ARGV[3]), 1)
    return 0  -- 被封禁
else
    return 1  -- 允许请求
end

📌 示例 5：原子性转账（多 Key 操作）

业务场景：从账户 A 转账到 B，必须保证两步操作要么全成功、要么全不做。

-- KEYS[1] = from_account
-- KEYS[2] = to_account
-- ARGV[1] = amount

local from_balance = tonumber(redis.call("GET", KEYS[1]))
local amount = tonumber(ARGV[1])

if from_balance >= amount then
    redis.call("DECRBY", KEYS[1], amount)
    redis.call("INCRBY", KEYS[2], amount)
    return 1  -- 转账成功
else
    return 0  -- 余额不足
end

如果你有某个具体的业务场景，我也可以帮你定制 Lua 脚本。是否需要我生成 Markdown 格式供你发布博客或文档？

5.2 乐观锁：WATCH

你可以使用 WATCH 监听一个或多个 key，当执行 EXEC 时，如果这些 key 被其他客户端修改过，则事务会失败（即 EXEC 返回 nil），开发者可以选择重试。

WATCH key1
MULTI
SET key1 "new-value"
EXEC   # 如果 key1 在此期间被改过，则 EXEC 不会生效

这适合需要 并发冲突检测 的业务逻辑。

5.3 最佳实践建议

  • 如果需要确保逻辑完整性，请使用 Lua 脚本而非 MULTI/EXEC。
  • 使用 WATCH 实现乐观并发控制，适合简单场景。
  • 避免在事务中执行有可能失败的命令，尤其是类型敏感命令（如 INCR、LPUSH 等）。
特性 Redis 事务支持？ 说明
命令打包执行原子性 ✅ 所有命令会串行执行
命令回滚 ❌ 任一命令失败不会影响其他命令
并发隔离 ❌ 没有隔离级别控制
整体原子执行 ❌（用 Lua 可实现） 推荐使用 Lua 脚本实现真正原子性

6、结语

Redis 事务提供的是一种“轻量级的命令打包执行”机制，满足了大多数高性能应用的需求。但若你需要 ACID 级事务保障，Redis 并不是你的首选，或许应该考虑 Redis 作为缓存层，数据库（如 PostgreSQL）作为持久化存储来共同协作。

动物装饰