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

在 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 操作的方式。

核心思路

1. 利用 Hash Tag 规则，强制相关 key 落在同一 slot；
2. 用 Lua 脚本在单节点内完成所有操作，天然原子。

实施步骤

1. Key 设计：使用{}包裹聚合 ID

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

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 keys = Arrays.asList(
    "user:{1001}:balance",
    "user:{1001}:orders",
    "user:{1001}:log");
List 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 等可靠队列处理：

A[发起操作] --> B[发消息到 MQ]
B --> C[消费者1: 更新 key1]
C --> D[消费者2: 更新 key2]

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

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

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

总结：如何选择？

核心原则：在 Redis Cluster 中，不要对抗 slot 机制，而要顺应它。通过合理的数据建模（聚合根 + Hash Tag），完全可以在享受 Cluster 高可用的同时，实现强一致的事务操作。