Beego 原生 RedisClusterConnPool 不支持自动拓扑发现与故障转移，需扩展 GetClusterNodes()、节点健康检查及 MOVED/ASK 重定向处理，并通过分片并行 SCAN、独立游标、连接池调优保障高可用。
Beego 默认不支持 Redis 集群高可用连接，直接用 redis.RedisClusterConnPool 会卡在节点发现、故障转移和重试逻辑上——尤其在主从切换或某节点临时不可达时，请求直接 panic 或超时返回 nil。
Beego 中 redis.ClusterClient 初始化失败的典型错误
常见现象是启动时报错：redis: cluster has no slots assigned 或 redis: dial tcp 127.0.0.1:6379: connect: connection refused，本质是 Beego 原生 RedisClusterConnPool 缺少自动节点探测与拓扑刷新能力。
关键原因有三个：
- Beego v2.1.0 内置的
RedisClusterConnPool不调用CLUSTER SLOTS或CLUSTER NODES动态获取分片映射，而是依赖静态配置地址列表 - 节点宕机后不会自动剔除，后续请求仍发往失效地址，触发连接级错误
- 没有实现客户端重定向（MOVED/ASK）响应解析，遇到重定向报文直接丢弃而非重试
必须手动扩展 GetClusterNodes() 和节点健康检查
Beego 的 RedisClusterConnPool 没有暴露 GetClusterNodes() 方法，需基于其源码做轻量扩展（非 fork 整个包），重点补全两件事：
- 在初始化时调用
conn.Do("CLUSTER NODES")，解析返回内容提取所有master节点的ip:port和所属 slot 范围 - 为每个节点维护一个
lastHealthyAt时间戳，每次执行命令前检查是否超过3s未成功通信，超时则跳过该节点并触发后台异步探测 - 封装
GetNodeConn(addr string)方法，确保复用连接池而非每次都Dial，避免too many open files
示例节选（utils/redis_cluster.go）：
func (p *RedisClusterConnPoolExt) RefreshNodes() error {
nodes, err := p.getClusterNodesFromAnyNode()
if err != nil {
return err
}
p.mu.Lock()
defer p.mu.Unlock()
p.nodes = filterMasters(nodes)
return nil
}
func (p *RedisClusterConnPoolExt) getClusterNodesFromAnyNode() ([]*clusterNode, error) {
for _, addr := range p.addrs {
conn, err := redis.Dial("tcp", addr)
if err != nil { continue }
defer conn.Close()
reply, err := conn.Do("CLUSTER NODES")
if err == nil {
return parseClusterNodes(reply)
}
}
return nil, errors.New("no healthy node responded to CLUSTER NODES")
}
SCAN 命令必须走分片并行 + 游标隔离
直接对集群 client 调用 SCAN 会命中单个随机节点，漏掉其余 16383 个 slot 上的数据。正确做法是：先获取全部 master 节点，再对每个节点并发执行 SCAN，且每个节点独立维护游标。
- 不要共用一个全局游标值；每个 goroutine 启动时设
cursor = 0，循环直到返回cursor == 0 - 结果合并前做一次
map[string]struct{}去重，防止哈希槽边界 key 被多个节点重复返回（极小概率，但存在） - 设置 per-node 超时（如
context.WithTimeout(ctx, 2*time.Second)），避免单个慢节点拖垮整体 - 若某节点 SCAN 失败，记录 warn 日志但继续其他节点，最终返回已扫描到的 keys —— 这比全盘失败更符合生产诉求
连接池参数必须按集群规模调优
Beego 配置里写的 redis.cluster.pool_size=10 是每个节点的连接池大小，不是全局总数。10 个 master 节点 × 10 连接 = 100 个 TCP 连接，容易打满 ulimit。
- 建议设为
pool_size = max(5, ceil(总节点数 × 1.5))，例如 6 节点集群设为 9 -
idle_timeout必须小于 Redis server 的timeout配置（默认 0 表示禁用），否则连接池可能归还一个已被服务端关闭的连接 -
min_retry_backoff和max_retry_backoff要拉开梯度（如 100ms → 300ms），避免雪崩式重试冲击同一节点 - 务必启用
read_timeout和write_timeout（推荐 2–3s），防止 SCAN 卡死阻塞整个 goroutine
真正麻烦的从来不是连上集群，而是当某个 master 节点正在 failover、slot 正在迁移、或者网络抖动导致 MOVED 响应延迟到达时，你的游标状态、重试计数、连接复用逻辑是否还能稳住——这些细节不在文档里，只在日志和压测中浮现。
