应使用 redis.NewClusterClient() 连接 Redis 集群，传入初始节点列表（至少2个），启用自动重定向与槽位路由，避免误用 NewClient()；Key 需通过 {tag} 控制哈希槽，禁用跨槽命令如 KEYS、事务等。
用 github.com/go-redis/redis/v9 连接 Redis 集群
Go 官方不提供 Redis 集群客户端，必须依赖第三方库；github.com/go-redis/redis/v9 是当前最成熟、维护活跃的选择，原生支持集群模式（非哨兵、非单节点）。它通过 redis.NewClusterClient() 构建客户端，自动处理槽位路由、重定向（MOVED/ASK）、故障转移和节点发现。
常见错误是误用 redis.NewClient() 连集群地址——这会导致命令直接发到某个节点，遇到跨槽操作时返回 MOVED 错误且不重试，程序崩溃或逻辑异常。
- 初始化时传入的是初始节点列表（至少 2 个），不是所有节点；客户端会自动获取集群拓扑
- 连接字符串格式为
redis://<host>:<port></port></host>，不带数据库编号（集群中SELECT不被支持） - 务必设置
RouteByLatency: true或RouteRandomly: true来控制读请求分发策略，否则默认只走主节点
处理 MOVED 和 ASK 重定向的底层机制
go-redis/v9 默认开启自动重定向，但你得知道它怎么工作：收到 MOVED 响应后，客户端更新本地槽位映射表，并重试命令；ASK 则临时转向目标节点执行一次，再刷新拓扑。这个过程对上层透明，但有边界条件：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 事务（
PIPELINE或WATCH/MULTI/EXEC）不支持跨槽——集群中所有 key 必须落在同一槽，否则直接报错CROSSSLOT Keys in request don't hash to the same slot - 某些命令如
KEYS、SCAN、FLUSHDB在集群下被禁用或限制；要用SCAN就得遍历每个节点，用redis.NewClient()单独连各节点再聚合结果 - 超时或网络抖动可能导致重定向失败，建议配置
MaxRedirects: 8（默认值）并捕获redis.Nil和redis.ClusterDownError等特定错误类型
Key 设计必须适配集群哈希规则
Redis 集群使用 CRC16(key) mod 16384 计算槽位，这意味着 key 的结构直接影响分布均匀性与跨槽风险。实际写代码时，不能靠运气——必须显式控制哈希行为：
- 用大括号包裹 tag，例如
user:{1001}:profile和user:{1001}:settings会落到同一槽，支持MGET、DEL批量操作 - 避免纯数字或递增 key（如
order_1,order_2），容易导致数据倾斜；可加随机前缀或哈希后缀，如order_1#f8a2 - 涉及关联查询的多个 key（如用户 + 订单 + 日志），若无法共用 tag，就得接受应用层 join，或改用单节点 Redis + 分库逻辑
健康检查与节点变更的实际应对
集群节点上下线、主从切换在生产中很常见，go-redis/v9 虽能自动刷新拓扑，但存在延迟窗口（默认每 2 分钟主动刷新，出错时立即触发）。问题常出现在刚扩容完就发请求，或某节点短暂失联后恢复但客户端还没同步新拓扑。
- 启用
ReadOnly: true并配合RouteByLatency可降低从节点不可用的影响 - 不要依赖
CLUSTER NODES输出做自定义发现——go-redis内部已封装完整逻辑，手动干预反而破坏一致性 - 监控关键指标：用
client.PoolStats()查看各节点连接数、空闲连接、等待请求数；配合redis.ClusterSlots()手动校验槽分配是否均衡
真正难的不是连上集群，而是理解哪些操作天然不兼容分布式语义——比如原子性跨槽事务、全局 key 统计、带模式的批量删除。这些地方没得绕，要么重构 key 结构，要么降级到单实例，或者换存储方案。
