直接用 SET key value EX seconds NX 做心跳不靠谱，因其无法保证更新基于最新状态，且缺乏原子性条件更新能力，易导致并发覆盖和非法状态跃迁。
为什么直接用 SET key value EX seconds NX 做心跳不靠谱
因为单次 SET 无法保证“更新必须基于最新状态”，多个服务实例并发写入时，后写入的会覆盖前一次的心跳时间，导致状态机误判节点下线。更关键的是，它不提供原子性条件更新能力——你没法在更新心跳的同时检查该节点当前是否处于 offline 状态并拒绝非法跃迁。
实操建议：
- 改用
EVAL执行 Lua 脚本，将“读当前状态 + 判断合法性 + 写新心跳 + 更新状态”打包为原子操作 - 心跳 key 设计为
heartbeat:{service}:{instance_id}，状态 key 为status:{service}:{instance_id}，避免跨服务干扰 - 不要依赖 TTL 自动过期来判断离线——网络抖动可能导致短暂超时，应由主控端主动探测 + 容忍窗口（如连续 3 次未更新才触发 offline）
Go 中用 redis.Client.Eval 实现带状态校验的心跳更新
核心是把状态跃迁规则固化在 Lua 脚本里，比如只允许 online → online 或 offline → online，禁止 online → offline 这类反向操作。
示例脚本逻辑（传入参数：instance_key, current_status, ttl_seconds）：
立即学习“go语言免费学习笔记（深入）”；
if redis.call("GET", KEYS[1]) == ARGV[1] then
redis.call("SET", KEYS[2], ARGV[1], "EX", ARGV[2])
return 1
else
return 0
endGo 调用时注意：
-
client.Eval(ctx, script, []string{status_key, heartbeat_key}, current_status, ttl)——status_key放前面用于条件读取，heartbeat_key放后面用于写入心跳时间戳 - 返回值为
int64，非 1 表示状态校验失败，需记录 warn 日志并跳过本次更新 - 别在 Lua 里调用
TIME或INCR等非确定性命令，否则集群模式下会报错CROSSSLOT Keys in request don't hash to the same slot
状态机同步不能只靠心跳 key 的存在与否
Redis key 是否存在，只能反映“最近有没有心跳”，不能代表“当前业务状态”。例如一个节点正在执行耗时任务，心跳正常但已无法处理新请求——这时光看 heartbeat:{x} 是不够的。
实操建议：
- 引入独立的业务状态 key，如
state:{service}:{instance_id}，值为 JSON 字符串：{"phase":"processing","task_id":"abc123","updated_at":1717023456} - 用
redis.Client.SetEX更新该 key，TTL 设为略大于最长任务预期耗时（比如 5 分钟），避免任务卡住后状态长期滞留 - 主控端聚合查询时，先查
heartbeat:*获取活跃节点列表，再批量MGET state:{service}:*补充业务上下文，两者缺一不可
如何避免 Redis 网络分区时的状态雪崩
当某台实例与 Redis 断连，它可能在本地继续运行并尝试重连，期间若持续用旧时间戳刷心跳，恢复连接后会批量覆盖其他节点的最新状态，导致整个状态机混乱。
关键控制点：
- 在 Go 服务启动时，用
redis.Client.Ping阻塞等待 Redis 可用，超时则 panic，不启动业务逻辑 - 心跳 goroutine 中，每次
EVAL前检查time.Since(lastSuccessTime) > 2 * heartbeatInterval，超过两倍间隔就主动标记自身为degraded并停止上报 - 所有状态变更（包括 offline 推断）必须由单一协调者（如 leader 节点或独立 watcher 服务）执行，禁止各实例自行决定“我下线了”
最易被忽略的是时间差：不同机器系统时钟偏差超过 TTL 容忍范围时，EX 设置的时间就不等价。上线前务必用 chrony 或 ntpd 对齐所有节点时间，误差控制在 100ms 内。
