Redis Cluster 多键操作与 Hash Tag 实战指南

1. 从单机到集群：Redis 架构升级的阵痛与挑战

那天凌晨三点，我被一阵急促的电话铃声惊醒。运维同事在电话那头焦急地说："刚切完 Redis Cluster，现在整个下单系统全挂了！"我瞬间清醒，抓起电脑就冲进了线上问题处理室。屏幕上满屏的 CROSSSLOT 报错像是一记重拳，让我意识到：从单机到集群的升级，远不是改个连接地址那么简单。

Redis Cluster 模式下，数据被分散存储在多个节点上，每个节点负责一部分哈希槽（Hash Slot）。默认情况下，Redis 会使用 CRC16 算法对 key 进行哈希计算，然后对 16384 取模来确定 key 应该存放在哪个槽位。这个机制带来了水平扩展的能力，但也引入了一个重要限制：涉及多个 key 的操作（如事务、Lua 脚本、MGET/MSET 等）要求所有 key 必须位于同一个槽位，否则就会抛出 CROSSSLOT 错误。

关键点：Redis Cluster 的多 key 操作原子性保证是基于单个槽位的，这是分布式系统 CAP 理论中一致性（Consistency）和分区容错性（Partition Tolerance）权衡的结果。

2. CROSSSLOT 错误的本质解析

2.1 哈希槽分配机制

Redis Cluster 将整个 key 空间划分为 16384 个槽位，这些槽位被均匀分配到集群中的各个主节点。当客户端发送一个命令时，集群会先计算 key 对应的槽位，然后将其路由到正确的节点执行。

槽位计算公式如下：

python复制def get_slot(key):
    # 只计算第一个 {} 之间的内容
    start = key.find('{')
    if start != -1:
        end = key.find('}', start+1)
        if end != -1 and end != start+1:
            key = key[start+1:end]
    return crc16(key) % 16384

2.2 多 key 操作的限制

在单机 Redis 中，我们可以随意地执行如下操作：

bash复制MGET user:1001:name user:1001