问题所在

Redis凭借高性能、低延迟的特性，广泛应用于缓存、分布式锁、限流、计数器等业务场景。单体Redis无法支撑海量数据与高并发流量，绝大多数线上生产环境，均采用Redis Cluster集群架构实现数据分片与读写扩容。

Lua脚本是Redis高频使用的高级特性，能够将多条Redis命令封装为一段脚本，以原子化方式执行，规避并发竞争问题，同时减少网络IO开销，常用于秒杀扣减、批量数据更新、分布式事务等场景。

单体架构中，Lua脚本可自由操作库内所有Key，无任何使用限制；但切换至集群架构后，随意通过Lua脚本操作多个Key，大概率触发程序异常，控制台抛出固定报错：CROSSSLOT Keys in request don't hash to the same slot。

案例

以电商业务场景为例，需要同步更新用户账户余额、用户积分两个数据，为保证操作原子性，采用Lua脚本封装两条更新命令，核心命令如下：

-- 批量更新用户余额与积分 redis.call('HINCRBY','user_balance_10086', 'money', -100) redis.call('HINCRBY','user_score_10086', 'score', 20) return true

该脚本在单机环境可正常执行；部署至Redis集群后直接执行失败。根本原因在于Redis Cluster的分片机制：

        集群共划分16384个哈希槽（Slot），所有Key会通过CRC16算法计算哈希值，再对16384取模，分配至对应哈希槽，不同哈希槽由集群内不同主节点负责维护。

上述案例中，user_balance_10086与user_score_10086两个Key经算法计算后，大概率分配至不同哈希槽，归属不同主机节点。而集群架构硬性规定：Lua脚本、MULTI事务、MGET批量查询等原子类操作，涉及的所有Key必须落在同一个哈希槽、同一个主节点。

该限制的核心目的：原子操作无法拆分分发至多个节点执行，集群无法同时向多个主机转发同一份Lua脚本，跨槽操作直接被集群拦截拒绝。针对这类跨节点、跨槽位的业务痛点，Redis官方提供专属解决方案——Hash Tag来解决这个问题。

咋用 Redis Hash Tag呢

语法规则

Hash Tag是Redis内置的Key路由强制绑定功能，语法规则极简：用一对大括号{}包裹Key中的指定片段，集群计算Key所属哈希槽时，不再基于完整Key计算，仅提取大括号内部的字符串执行CRC16哈希运算，最终将Key路由至对应槽位。

案例

沿用上述电商用户数据更新案例，通过Hash Tag改造两个冲突Key，将用户ID作为标签核心内容，保证两个Key的哈希计算依据完全一致：

-- 改造前（随机分配槽位，跨节点报错） user_balance_10086、user_score_10086 -- 改造后（绑定统一哈希标签） {user_10086}_balance、{user_10086}_score

同步更新改造后的Lua脚本，脚本可在集群环境正常执行：

-- 基于Hash Tag的原子更新脚本 redis.call('HINCRBY','{user_10086}_balance', 'money', -100) redis.call('HINCRBY','{user_10086}_score', 'score', 20) return true

规范

• 单个Key允许仅设置一对大括号；若存在多对，仅解析第一对大括号内的内容；

• 若大括号内部为空，Hash Tag失效，集群恢复基于完整Key计算哈希槽；

• Hash Tag不仅适配Lua脚本，同时兼容集群事务、批量命令（MSET/MGET）等所有受槽位限制的操作；

• Java客户端使用时无需额外依赖，直接在代码中编写带标签格式的Key即可，原生适配Redis集群规则。

底层工作原理

原生Key路由逻辑

无Hash Tag时，Redis集群路由Key的完整流程：

1. 接收客户端操作指令，提取指令中待操作的完整Key字符串；

2. 调用CRC16算法对完整Key进行哈希计算，得到固定哈希值；

3. 用哈希值对16384取模，得出0~16383范围内的哈希槽编号；

4. 根据槽位映射关系，将指令转发至对应主节点执行。

带Hash Tag Key路由逻辑

启用Hash Tag后，集群仅修改哈希计算的数据源，整体路由流程不变，核心改动如下：

1. 解析Key字符串，检索{}符号并提取括号内部的子字符串；

2. 放弃完整Key，仅针对提取出的子字符串执行CRC16哈希运算；

3. 通过取模运算匹配哈希槽，完成节点路由。

问题解决核心逻辑

结合改造案例分析：{user_10086}_balance与{user_10086}_score两个Key，标签内部字符串均为user_10086。集群计算槽位时，两次运算的数据源、哈希值、取模结果完全一致，两个Key会被强制分配至同一个哈希槽，由同一台主节点负责管理。

此时Lua脚本操作的所有Key均归属单节点，集群无需拆分指令，直接转发至对应主机执行，从根源规避跨槽、跨节点报错，同时完整保留Lua脚本的原子执行特性。

额外补充：Hash Tag本质属于人工干预分片规则，大规模业务中，可基于业务维度（用户ID、订单ID、活动ID）设计标签，实现同业务关联数据聚合分片，既适配原子操作，又能优化热点数据访问效率。

八股式一句话总结

Redis Hash Tag通过大括号截取Key内指定字符串作为哈希计算依据，强制多个关联Key映射至同一哈希槽与集群节点，解决集群环境下Lua脚本、事务等原子操作因跨槽跨节点触发的CROSSSLOT报错问题，适用于关联数据原子操作场景。

写在最后

Hash Tag是Redis集群高阶开发的必备知识点，使用门槛低、适配场景广，但开发过程中需规避滥用问题。过度集中相同标签的Key，会导致数据分片倾斜，部分节点数据量、访问量过高，引发热点节点性能瓶颈。实际开发中需结合业务体量，平衡原子操作需求与数据分片均匀性。