mset在redis cluster中易因key跨slot、批量过大导致倾斜或失败；应使用哈希标签{...}强制同slot，控制单次不超过64个key且总大小不超1mb，或改用pipeline分片处理。
MSET 能显著减少网络延迟，但在 Redis Cluster 上直接批量写入大量 key 很容易触发跨 slot 请求、缓冲区溢出或节点负载不均——这不是命令本身的问题，而是没控制好 key 分布和批量粒度。
为什么 MSET 在集群里会倾斜甚至失败
Redis Cluster 按 key 计算 CRC16 % 16384 得到 hash slot，每个 slot 只属于一个节点。MSET 命令要求所有 key 必须落在同一个 slot 才能原子执行；否则客户端会报 MOVED 或 ASK 错误，部分客户端（如老版 Jedis）甚至直接抛 RedisClusterException。更隐蔽的问题是：即使客户端自动重试分片请求，MSET 也会被拆成多个单 key 请求发往不同节点，彻底失去批量意义，还可能把流量集中打向某几个热 slot 对应的节点。
- 用
CLUSTER KEYSLOT key手动验证过 key 分布，发现 100 个 key 散在 20+ 个 slot 上 - 未加前缀或哈希标签（
{user123}）的业务 key，天然无法保证同 slot - 批量 size 过大（如一次
MSET传 5000 个 key），单次请求包超 16MB，触发client-output-buffer-limit熔断
用哈希标签强制 key 落在同一 slot
这是最直接、对业务侵入最小的解法。只要把需要批量操作的 key 归到同一逻辑组，并用 {...} 包裹相同前缀，Redis 就只对花括号内字符串做 slot 计算。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确写法：
MSET {user:1001}:name "Alice" {user:1001}:age "30" {user:1001}:city "Beijing"→ 全部落到同一 slot - 错误写法：
MSET user:1001:name "Alice" user:1001:age "30"→ 每个 key 单独计算 slot，大概率分散 - 注意嵌套：
{order:{12345}}:status和{order:{12345}}:items是合法的，外层{}决定 slot - 别滥用：全用
{global}会导致所有 key 打到一个节点，彻底破坏集群均衡
控制单次 MSET 的 key 数量与字节大小
官方没硬性上限，但生产环境必须按实际链路压测。重点不是“最多能塞多少”，而是“多大时延迟开始非线性上升”。实测表明：
- 单次
MSET控制在64个 key 以内，平均响应时间稳定在0.8ms左右（局域网） - 超过
256个 key 后，Redis 主线程解析参数耗时陡增，且易触发客户端 socket buffer 溢出 - 总 payload（key+value 字节数之和）建议不超过
1MB；若 value 是 JSON，先压缩再存，比盲目扩 buffer 更可靠 - Spring Boot 中用
StringRedisTemplate.opsForValue().multiSet(Map)时，底层就是MSET，同样受此限制
当无法加哈希标签时，改用 Pipeline + 分片
如果 key 语义上不能强绑定（比如日志 ID、随机 token），就放弃 MSET 的原子性，转而用 Pipeline 手动分片。这不是退步，而是更可控的工程选择。
- 先按
CLUSTER KEYSLOT key把待写 key 分成若干组，每组对应一个 slot（也就是一个目标节点） - 对每组调用
pipeline.mset(Map)（Lettuce）或pipeline.multi().set(...).set(...)（Jedis） - 每组 key 数仍遵守
64上限，避免单 pipeline 请求过大 - 不要用
pipeline.sync()阻塞等待，改用pipeline.exec()返回List<object></object>异步处理结果
最容易被忽略的是：哈希标签不是万能的，它把数据局部性交给了业务设计；而 Pipeline 分片看似麻烦，却把分布逻辑显式暴露出来，反而更容易监控 slot 热点和做熔断。线上真正出问题的，往往不是命令不会用，而是没确认过 key 到底落在哪个 slot 上。
