一、基础原理
1. 单条命令执行流程
客户端发送命令 → Redis 服务端执行 → 返回结果。一次1 次网络往返。
2. 串行 N 条命令（普通 for 循环逐条执行）
公式：总耗时 = N次网络往返耗时 + N次命令执行耗时 缺点：大量网络 IO，性能极差。
3. MSET 和 Pipeline 批量方案
- MSET：Redis 内置批量命令，一次性写入多个 key-value；只能操作 String 类型，类似还有 HMSET（hash）。
- Pipeline（管道） ：客户端把多条命令缓存，一次性发给 Redis，服务端依次执行，一次性返回全部结果。支持所有 Redis 命令、所有数据类型，通用性更强。
核心共同点：一次网络往返，减少网络开销。
二、集群环境的致命限制
Redis Cluster 有 16384 个 slot（插槽），key 根据 hash 计算落到对应 slot，不同 slot 可能在不同节点。
✅ 规则：MSET / Pipeline 一次请求里的所有 key，必须落在同一个 slot，否则直接报错执行失败 。 原因：集群一次请求只能发给一个 Redis 节点，key 跨 slot 就分布在不同节点，节点无法处理不属于自己 slot 的 key。
三、4 种集群批量写入方案对比
表格
| 方案 | 实现思路 | 耗时 | 优点 | 缺点 |
|---|---|---|---|---|
| 串行命令 | for 循环遍历，逐条执行命令 | N 次网络耗时 + N 次命令耗时 | 实现最简单 | 网络次数多，耗时非常久 |
| 串行 slot | 客户端预计算每个 key 的 slot，按 slot 分组；同一 slot 的 key 用 Pipeline 批量，分组串行执行 | m 次网络耗时 + N 次命令耗时m=slot 分组数量 | 耗时较短 | 实现稍复杂；slot 分组越多，耗时越长 |
| 并行 slot | 客户端预计算 slot 分组，多线程并行执行各组 Pipeline | 1 次网络耗时 + N 次命令耗时 | 耗时极短 | 代码逻辑复杂，需要多线程处理 |
| hash_tag | 给所有 key 设置相同 hash_tag（{tag}key），强制所有 key 落到同一个 slot |
1 次网络耗时 + N 次命令耗时 | 耗时极短、代码简单 | 容易数据倾斜，所有 key 压在同一个节点，负载不均衡 |
hash_tag 原理：
{xxx}key1，只会对{}内的内容做 hash 计算 slot，{user}1、{user}2slot 完全相同。