Lua 脚本与事务

总览: 原子性的两条路

前五篇积累了大量单条命令的用法. 但真实场景中, 一个业务操作往往需要多条命令配合完成--分布式锁要先 GET 再 DEL(05 篇的释放锁), 扣库存要先 GET 再 SET, 限流要先 INCR 再判断. 如果这些命令之间被其他客户端的命令插入, 就会出现竞态条件(Race Condition).

Redis 提供了两条路来保证多命令的原子执行:

1. Redis 事务(Transaction)

1.1 MULTI / EXEC 基础

事务的三个关键命令:

# 场景: 转账 -- A 减 100, B 加 100
MULTI
DECRBY account:A 100
INCRBY account:B 100
EXEC
→ 1) (integer) 900    ← A 的结果
→ 2) (integer) 1100   ← B 的结果

# 在 MULTI 和 EXEC 之间, 其他客户端无法插入命令
# 这保证了"A 扣了但 B 没加"不会发生

事务的关键特性:

• 串行执行: EXEC 时命令一次性顺序执行, 不会被打断
• 没有回滚: 即使中间某条命令执行失败, 后面的命令继续执行. 前面的命令不会撤销.
• 入队时只做语法检查: MULTI 期间命令入队时只检查语法错误(参数数量不对等), 执行期错误(如对 String 做 LPUSH)不影响其他命令

1.2 为什么 Redis 事务没有回滚?

这可能是从关系数据库(MySQL/Postgres)转过来的开发者最大的困惑. Redis 官方对此的解释是:

1. Redis 命令的设计哲学: 命令本身设计得足够简单, 语法错误应该在开发阶段就被发现, 不应该到生产环境才暴露.
2. 性能优先: 回滚机制需要维护 undo log 等额外结构, 与 Redis 的极简高性能定位冲突.
3. 实际收益低: Redis 命令的执行期错误大多是编程错误(如类型不匹配), 这类错误无法通过回滚修复--需要的是修代码, 而不是撤销操作.

# 演示: 事务中的执行期错误不会回滚
SET k1 "hello"
MULTI
INCR k1               ← 入队不报错(语法 OK)
SET k2 "world"
EXEC
→ 1) (error) ERR value is not an integer   ← INCR 对字符串执行失败
→ 2) OK                                     ← 但 SET 仍然执行了!

1.3 WATCH: 乐观锁(Optimistic Locking)

WATCH 是实现**CAS(Compare-And-Swap)**的关键. 它监控一个或多个 key, 在执行 EXEC 之前, 如果这些 key 被其他客户端修改了, EXEC 会返回 (nil), 整个事务被取消.

# 场景: 抢最后一个库存(乐观锁版本)

# --- 客户端 A ---
WATCH stock:item_1001       ← 监控库存 key
GET stock:item_1001         → "1"(还剩 1 件)
MULTI
DECR stock:item_1001        ← 扣库存
# 此时在 A 的 EXEC 之前, 客户端 B 抢先:
#   DECR stock:item_1001 → 0

EXEC                        ← A 的 EXEC
→ (nil)                     ← 事务被取消! 因为 stock 已被 B 修改

# A 的处理: 重试
UNWATCH
WATCH stock:item_1001
GET stock:item_1001         → "0"(库存为 0, 不再下单)

WATCH 的限制:

1. 只能在 MULTI 之前使用, 不能在事务内部 WATCH
2. 它监控的是整个 key 的值变化, 不是某个 field 的变化
3. 高并发下重试次数可能很高, 此时更适合用 Lua 脚本

1.4 事务的适用边界

2. Lua 脚本

2.1 为什么需要 Lua?

Redis 选择嵌入 Lua 解释器, 解决了一个核心矛盾: 原子性 vs 灵活性. 事务能保证原子性但太僵硬(不能做判断), 而一次发多条命令又无法保证原子性. Lua 脚本在 Redis 服务端执行, 把"逻辑判断 + 数据操作"打包成一个原子单元.

2.2 EVAL / EVALSHA

# 最简单的 Lua 脚本: 返回 "hello"
EVAL "return 'hello'" 0
→ "hello"

# 带参数: 返回第 2 个 ARGV 参数
EVAL "return ARGV[2]" 0 arg1 arg2 arg3
→ "arg2"

# 操作 key: 对指定 key 做 INCR
EVAL "return redis.call('INCR', KEYS[1])" 1 counter:test
→ (integer) 1

Lua 数组从 1 开始(不是 0), 且 KEYS 和 ARGV 是两个独立的数组.

2.3 KEYS[] 与 ARGV[] -- 为什么必须区分?

很多初学者的第一个 Lua 脚本是把所有参数都塞进 ARGV:

-- ❌ 错误示范: key 当 arg 传
EVAL "return redis.call('GET', ARGV[1])" 0 mykey
-- 能跑, 但集群模式下会出问题

在 Redis Cluster 中, 每个 key 根据 hash slot 分布在不同的节点上. 如果脚本操作的 key 没有通过 KEYS[] 正确声明, Redis 就不知道应该把脚本路由到哪个节点, 也不知道脚本是否合法(集群要求一个脚本操作的所有 key 必须在同一个 slot).

# ✅ 正确示范: key 和 arg 分开
EVAL "return redis.call('SET', KEYS[1], ARGV[1], 'EX', ARGV[2])" 1 mykey "hello" 60

# KEYS[1] = mykey   (key, 要被集群路由)
# ARGV[1] = hello   (value, 运行参数)
# ARGV[2] = 60      (过期秒数, 运行参数)

2.4 Hash Tag: 让多个 key 落到同一个 Slot

在 Redis Cluster 中, key 通过 CRC16(key) % 16384 计算出 hash slot, 数据分布在不同节点上. Lua 脚本的硬性要求是: 脚本操作的所有 key 必须在同一个 slot, 否则执行时报错:

EVAL "return redis.call('MGET', KEYS[1], KEYS[2])" 2 user:1:name user:1:age
→ (error) CROSSSLOT Keys in request don't hash to the same slot

user:1:name 和 user:1:age 虽然是同一个用户的数据, 但它们的 key 字符串不同, hash 后大概率落在不同的 slot--这就是跨 slot 错误.

Hash Tag 的语法

Redis Cluster 提供了一种特殊规则: 如果 key 中包含 {...}(一对花括号), 那么只有花括号内部的内容参与 hash 计算, 花括号外部的部分被忽略.

-- 没有 Hash Tag: 整个 key 参与 hash
CRC16("user:1:name") % 16384  → slot A
CRC16("user:1:age")  % 16384  → slot B   ← 不同 slot!

-- 有 Hash Tag: 只 hash 花括号内的部分
CRC16("{user:1}:name") % 16384 → slot X
CRC16("{user:1}:age")  % 16384 → slot X  ← 相同 slot! 因为都只 hash "user:1"

在 Lua 脚本中使用 Hash Tag

沿用上面的例子, 加上 Hash Tag 后跨 slot 问题就解决了:

# ✅ 用 Hash Tag 把同一用户的 key 绑定到同一 slot
EVAL "return redis.call('MGET', KEYS[1], KEYS[2])" 2 "{user:1}:name" "{user:1}:age"
→ 1) "张三"
→ 2) "25"

实际项目中的 key 命名惯例:

# 方案 A: 把业务主体放在花括号内
{user:1001}:profile
{user:1001}:followers
{user:1001}:settings
→ 所有 user:1001 的数据落在同一 slot

# 方案 B: 用固定前缀做 Tag(按业务域聚合)
{shop}:orders:2024-06-01
{shop}:products:featured
{shop}:inventory:sku_1001
→ 所有 shop 域的数据落在同一 slot(可能热点)

什么时候可以不用 Hash Tag?

并不是所有多 key 操作都必须在同一 slot. 以下情况自然兼容:

1. 单实例 / 主从模式: 没有 Cluster 的分片概念, 所有 key 都在同一个节点上, Hash Tag 完全不需要.
2. 脚本只操作一个 key: 单个 key 总在同一 slot, 天然满足要求.
3. 多 key 但恰好 hash 到了同一 slot: 概率极小但理论上可能存在--不能依赖这一点.

Hash Tag 的代价与注意事项

2.5 redis.call vs redis.pcall

两者都在 Lua 中执行 Redis 命令, 区别在于错误处理:

-- redis.call: 错误即终止
local val = redis.call("INCR", KEYS[1])   -- 如果 KEYS[1] 是 String 类型, 脚本报错退出

-- redis.pcall: 错误可捕获
local result = redis.pcall("INCR", KEYS[1])
if type(result) == "table" and result.err then
    return "ERR: " .. result.err
end
return result

2.6 实战脚本示例

示例 1: 原子扣库存(解决超卖)

-- KEYS[1]: 库存 key
-- ARGV[1]: 扣减数量
-- 返回: 剩余库存(负值表示库存不足)

local stock = redis.call("GET", KEYS[1])
if not stock then
    return -1
end
stock = tonumber(stock)
local deduct = tonumber(ARGV[1])
if stock < deduct then
    return -1
end
redis.call("DECRBY", KEYS[1], deduct)
return stock - deduct

# 执行
SET stock:item_1001 10
EVAL "..." 1 stock:item_1001 3
→ (integer) 7    ← 剩余 7 件

示例 2: 安全释放分布式锁

-- KEYS[1]: 锁 key
-- ARGV[1]: 客户端 token

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

示例 3: 滑动窗口限流(05 篇的精简版)

-- KEYS[1]: ZSet key
-- ARGV[1]: 窗口大小(毫秒)
-- ARGV[2]: 限额
-- ARGV[3]: 当前时间戳(毫秒)
-- ARGV[4]: 唯一标识(时间戳 + 随机数)

local window = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local member = ARGV[4]

redis.call("ZREMRANGEBYSCORE", KEYS[1], 0, now - window)
local count = redis.call("ZCARD", KEYS[1])

if count >= limit then
    return 0    -- 限流
end

redis.call("ZADD", KEYS[1], now, member)
redis.call("EXPIRE", KEYS[1], math.ceil(window / 1000) + 1)
return 1        -- 放行

示例 4: CAS 更新("版本号匹配才写")

-- KEYS[1]: 数据 key
-- ARGV[1]: 期望的版本号
-- ARGV[2]: 新值
-- 返回: 1=更新成功, 0=版本冲突

local data = redis.call("GET", KEYS[1])
if not data then
    redis.call("SET", KEYS[1], ARGV[2])
    return 1
end

-- 假设 value 格式: "version:payload"(如 "3:hello world")
local parts = {}
local i = 0
for part in string.gmatch(data, "([^:]+)") do
    i = i + 1
    parts[i] = part
end

local current_version = tonumber(parts[1])
local expected = tonumber(ARGV[1])

if current_version == expected then
    local new_value = (current_version + 1) .. ":" .. ARGV[2]
    redis.call("SET", KEYS[1], new_value)
    return 1
else
    return 0
end

2.7 脚本缓存机制

每次 EVAL 都把完整脚本传到服务端, 脚本越长带宽浪费越大. Redis 提供了脚本缓存机制:

# 经典用法: 先尝试 EVALSHA, 失败则 EVAL 并缓存
SCRIPT LOAD "return redis.call('INCR', KEYS[1])"
→ "e0b0f5a4b4e3c7c3a3a3b3c3d3e3f3a3b3c3d3e3"   ← SHA1 摘要

EVALSHA e0b0f5a4b4e3c7c3a3a3b3c3d3e3f3a3b3c3d3e3 1 counter:test
→ (integer) 1

大多数 Redis 客户端(Jedis, Lettuce, go-redis 等)已封装了 EVALSHA + fallback EVAL 逻辑: 先尝试 EVALSHA, 收到 NOSCRIPT 错误时自动 EVAL 并缓存.

3. 事务 vs Lua 选型对比

4. 常见陷阱

快速回顾