Redis Cluster客户端初始化必须主动Ping校验，否则错配密码、槽位未分配或节点网络不通等错误将延迟至首次Get/Set才暴露；需用带3秒超时的Ping立即验证连接可用性，失败则panic退出。
用 net.DialContext 做 TCP 层探测，别依赖 HTTP
HTTP /healthz 看起来直观，但实际故障定位慢、干扰多。一次 DNS 解析卡住或 TLS 握手 hang 住，http.Client 就会阻塞，且无法区分是网络不通、端口未监听，还是服务进程卡死。
真实场景下，只要 net.DialContext 能连上目标 addr（如 "10.0.1.5:8080"），就说明：网络可达 + 端口开放 + 进程正在 listen。这比等 HTTP 响应快一个数量级，也更准。
- 必须设两级超时：
context.WithTimeout控制整体（含 DNS），建议600ms；net.Dialer.Timeout单独控 connect 阶段，建议500ms - 连上后立刻
conn.Close()，不发任何数据——避免误触业务协议（比如打到 gRPC 端口触发 protocol error） - 失败不 panic，只更新本地状态；成功也不直接标为
Up，要结合连续成功次数去抖
状态机必须带滑动失败计数和恢复阈值
单次探测失败 ≠ 节点宕机。跨 AZ 网络抖动、宿主机 GC 暂停、内核 socket 队列拥塞，都可能导致一次 net.DialContext 超时。靠单点判断，线上必然频繁震荡上下线。
每个节点需维护两个字段：failCount 和 lastFailTime：
立即学习“go语言免费学习笔记（深入）”；
- 每次失败：若距上次失败 failCount++；否则重置为 1
-
failCount >= 3才触发Down事件 - 恢复判定需连续 2 次成功，且间隔 > 500ms，防止短暂通断反复触发
- 别用全局
map[string]NodeState加sync.RWMutex——高并发下锁争用严重；改用sync.Map或分片锁
集群地址发现与心跳上报不能耦合在同一个 client
很多实现把“发现其他节点”和“向注册中心上报心跳”混在一起，结果一出问题全瘫。比如 etcd 不可用时，节点既无法拉取最新集群拓扑，又无法上报心跳，状态雪崩。
正确做法是拆开：
- 节点发现走独立路径：启动时从配置中心（Vault / Consul KV）读取初始节点列表，再通过 Gossip 协议动态收敛；不依赖心跳通道
- 心跳上报走另一路：固定间隔（如 10s）用
http.Put或 gRPCUpdate向注册中心提交，内容含nodeID、ip、port、timestamp、version - 上报必须幂等：
nodeID作为 key，重复提交不引发状态抖动；注册中心只更新lastHeartbeatAt字段 - 上报失败不重试无限次——最多 3 次指数退避（100ms → 150ms → 225ms），之后静默丢弃，靠探测机制兜底
Redis Cluster 客户端初始化必须主动 Ping 校验
用 redis.NewClusterClient 初始化后，它不会在构造函数里校验连接是否真正可用。错配密码、槽位未分配、某个节点网络不通……这些错误全部延迟到第一次 Get 或 Set 才暴露，导致服务启动成功却实际不可用。
必须在初始化完成后立刻执行一次带超时的 Ping：
- 写法：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second); defer cancel(); err := rdb.Ping(ctx).Err() - 如果
err != nil，立刻 panic 或退出，别让带病服务上线 - 别漏掉任一节点的密码配置——错误信息常是模糊的
NOAUTH Authentication required，而非指出具体哪个节点没配 - 连接池参数必须显式设置：
PoolSize按公式算（预估 QPS × 2 ÷ 节点数），单节点上限别超 200；MinIdleConns设为 5，MaxConnAge设为30 * time.Minute
真实系统里最常被忽略的，是探测与上报两条链路的独立性设计。一旦注册中心不可用，节点发现还能靠本地缓存+Gossip 维持，而存活判定靠 TCP 探测兜底——这种解耦才是多活架构的底层支点。
