在 Redis Cluster 分片模式下规划消息队列 Key 分布，核心是通过哈希标签（Hash Tag）保证单队列内数据的槽位一致，并通过多队列分片策略避免单节点热点。适用于需要高吞吐且允许消息乱序或业务层分片的场景，风险边界在于单 Key 队列会导致集群负载不均。
先说结论：Redis Cluster 中单个 Key 只能落在一个槽位，消息队列若追求高性能需将队列拆分为多个 Key 分片，若追求强顺序则需接受单槽位热点风险。
- 适合：高并发写入、业务允许并行消费或自定义分片逻辑的场景
- 先看：使用 `{}` 哈希标签确保关联数据（如队列元数据与消息列表）落在同一槽位
- 建议：通过业务 ID 取模生成多个队列 Key，将流量均匀分散到 16384 个槽位中
命令速用版
# 查看 Key 所在的槽位
CLUSTER KEYSLOT queue:order:{1001}
# 强制将关联 Key 分配到同一槽位（使用哈希标签）
SET queue:task:{100}_info "meta"
LPUSH queue:task:{100}_list "message"
# 查看集群槽位分布状态
CLUSTER SLOTS为什么会这样
Redis Cluster 采用虚拟槽分区机制，全集群共有 16384 个哈希槽，Key 通过 CRC16 算法计算后映射到特定槽位。
单个 Key 不会分布到多个节点，这意味着如果所有消息都写入同一个 Key（如 `mq:global`），该 Key 对应的槽位所在节点将成为性能瓶颈。公开资料中没有看到可靠的量化数据说明单 Key 热点的具体阈值，但原理上该节点需承担该 Key 的所有读写流量。使用 `{}` 包裹的部分作为哈希计算因子，可强制让 `queue:{1}_list` 和 `queue:{1}_meta` 落在同一槽位，保障事务一致性，但无法解决单队列本身的负载集中问题。
分步处理
1. 确定分片数量：根据集群节点数和预期吞吐量，规划队列分片数（如 10 个分片对应 10 个 Key）。
2. 设计 Key 命名：采用 `业务前缀:{分片 ID}:数据类型` 格式，例如 `order:{0}:list` 到 `order:{9}:list`。
3. 客户端路由改造：生产者在发送消息前，对订单 ID 或用户 ID 取模（`id % 分片数`），决定写入哪个分片 Key。
4. 消费者组配置：每个消费者实例监听特定分片，或所有消费者竞争消费多个分片，需确保同一分片的消息顺序性由单消费者保障。
怎么验证是否生效
使用 `CLUSTER KEYSLOT` 命令检查不同分片 Key 是否分散在不同槽位。若 `order:{0}:list` 和 `order:{1}:list` 计算出的槽位差异较大且分布在不同主节点上，说明分布生效。通过 `INFO stats` 观察各节点的 `instantaneous_ops_per_sec`，若数值接近则说明负载相对均衡。若发现某节点 ops 远高于其他节点，需检查是否某个分片 Key 被过度使用。
常见坑
1. 多 Key 事务限制：Redis Cluster 不支持跨槽位的多 Key 事务，若业务逻辑依赖 `multi_key` 操作，必须确保所有涉及 Key 使用相同的哈希标签 `{}`。
2. 大 Key 风险：单个队列 Key 中成员数量过多会导致操作阻塞，建议单个 Key 成员数量控制在合理范围，公开资料建议集合类型元素数量小于 1000 或单个 Value 小于 10KB 以避免 BigKey 问题。
3. 扩容迁移成本：增加集群节点时，槽位会重新平衡，若 Key 设计未使用哈希标签，可能导致大量数据迁移，使用 `{}` 固定槽位可减少关联数据的迁移复杂度。
常见问题
单个消息队列 Key 能跨节点存储吗？
不能，Redis Cluster 中单个 Key 只会映射到一个哈希槽，因此只能存储在一个主节点上。
哈希标签 {} 会影响性能吗？
不会显著影响性能，它仅改变 CRC16 计算的输入字符串部分，主要用于控制数据分布位置。
如何保证消息顺序性？
在分片模式下，需保证同一业务流的消息始终写入同一个分片 Key，并由单个消费者实例顺序消费该 Key。
参考来源
- Redis Cluster 分区键设计方案（知识库资料）
- redis cluster 如何优化 key 使其分布均衡（知识库资料）
- Redis 集群中 Key 用法的最佳实践（知识库资料）
- Redis Clustering Best Practices With Multiple Keys | Redis（知识库资料）