Redis Cluster 实现多key事务操作的示例_Redis

在 redis 集群模式下，multi/exec 事务直接报错： “crossslot keys in request don't hash to the same slot”。那么，如何在保证数据一致性的前提下，同时操作多个 key？本文给出生产级可行方案，从原子性到最终一致性全覆盖。

如果你正在使用 redis cluster，一定遇到过这样的困境：

想扣用户余额，同时创建订单、记录日志；
写了个 multi/exec，结果 redis 报错：key 不在同一个 slot；
改用 pipeline？但又怕中间被其他请求插队，导致状态不一致……

别急！redis cluster 虽然限制了跨 slot 的原子操作，但通过合理设计，我们依然能实现安全、可靠、高性能的多 key 操作。

一、为什么 redis cluster 不支持跨节点事务？

redis cluster 将 key 空间划分为 16384 个 slot，每个 key 通过 crc16(key) % 16384 映射到一个 slot，由某个主节点负责。

而 multi/exec 事务要求所有 key 必须属于同一个 slot，否则直接拒绝：

> multi
> set user:1001:name alice
> set order:2001:status paid
> exec
(error) crossslot keys in request don't hash to the same slot

原因很简单：事务需要在单个节点上原子执行，而跨 slot 意味着涉及多个物理节点 —— redis 无法保证分布式事务的 acid。

⚠️ 注意：pipeline 也不是事务！它只是网络优化，命令之间仍可能被其他客户端插入。

二、方案一：hash tag + lua 脚本（强一致性，推荐！）

这是 唯一能在 redis cluster 中实现原子多 key 操作的方式。

✅ 核心思想：

利用 hash tag 规则，强制相关 key 落在同一 slot；
用 lua 脚本 在单节点内完成所有操作，天然原子。

🔧 实施步骤

1. key 设计：使用{}包裹聚合 id

redis 规定：只有 {} 内的内容参与 slot 计算。

# 所有与用户 1001 相关的 key
user:{1001}:balance   → slot = crc16("1001") % 16384
user:{1001}:orders    → slot = crc16("1001") % 16384
user:{1001}:log       → slot = crc16("1001") % 16384

✅ 这些 key 必然落在同一节点，可被原子操作。

2. 编写 lua 脚本（原子执行）

-- 扣款 + 加订单 + 记日志
local balance = tonumber(redis.call('get', keys[1]) or 0)
if balance < tonumber(argv[2]) then
    return redis.error_reply('insufficient_balance')
end

redis.call('decrby', keys[1], argv[2])          -- 扣余额
redis.call('sadd', keys[2], argv[1])            -- 加订单
redis.call('rpush', keys[3], 'order created')   -- 记日志

return balance - tonumber(argv[2])

3. 客户端调用（以 jedis 为例）

string script = "..."; // 上述 lua
list<string> keys = arrays.aslist(
    "user:{1001}:balance",
    "user:{1001}:orders",
    "user:{1001}:log"
);
list<string> args = arrays.aslist("order_2026", "100");

object result = jedis.eval(script, keys, args);

✅ 优势

强原子性：脚本执行期间，其他命令无法插入；
高性能：一次网络往返；
完全兼容 cluster。

⚠️ 注意事项

避免数据倾斜：不要用高频 id（如 user_id=1）作为 tag；
仅适用于“聚合根”模型：所有 key 应属于同一业务实体（用户、订单、会话等）。

💡 最佳实践：在领域建模阶段，就将需原子操作的数据归为同一聚合，并用 {aggregate_id} 作为 hash tag。

三、方案二：应用层分步操作 + 补偿机制（最终一致性）

当 key 无法归到同一 slot（如跨用户转账），且业务可接受最终一致性时，可采用 saga 模式。

示例：用户 a 转账给用户 b

try {
    // 1. 冻结 a 的资金（带 ttl 防死锁）
    redis.setex("lock:a:100", 30, "100");
    
    // 2. 扣 a 余额
    redis.decrby("user:a:balance", 100);
    
    // 3. 加 b 余额
    redis.incrby("user:b:balance", 100);
    
    // 4. 清除锁
    redis.del("lock:a:100");
} catch (exception e) {
    // 补偿：回滚已执行的操作
    if (a余额已扣) redis.incrby("user:a:balance", 100);
    if (b余额已加) redis.decrby("user:b:balance", 100);
    redis.del("lock:a:100");
}

✅ 适用场景

跨聚合根操作（如 a→b 转账）；
有明确补偿逻辑（如退款、撤回）；
可容忍短暂不一致。

❌ 劣势

实现复杂（需幂等、重试、监控）；
无法保证强一致性。

四、方案三：异步队列 + 幂等消费（高吞吐场景）

将多 key 操作拆解为消息，交由 kafka/rocketmq 等可靠队列处理：

graph lr
a[发起操作] --> b[发消息到 mq]
b --> c[消费者1: 更新 key1]
c --> d[消费者2: 更新 key2]

消费者需实现幂等（如用 set key value nx 防重）；
适合非实时场景：积分发放、通知推送、日志同步等。

五、不推荐方案：单独部署非集群 redis

为事务单独维护一套 standalone redis；
破坏架构统一性，增加运维成本；
丧失 cluster 的高可用与扩展能力；
仅适用于极小规模、临时过渡场景。

🔚 总结：如何选择？

场景	推荐方案
强一致性 + 多 key 同业务实体	✅ hash tag + lua 脚本
跨实体 key + 可接受最终一致	✅ saga 补偿或异步队列
简单批量读写（同 key）	✅ mset / mget（内置原子命令）