不能直接用 set key value nx 做选举，因为真实选举需“抢锁+写元数据+设过期”三步原子执行，拆分会导致状态不一致；必须用 lua 脚本将 exists、set 锁与 set 元数据打包为原子操作，并统一 key slot 以支持集群。
为什么不能直接用 SET key value NX 做选举
因为单次 SET ... NX 只能抢一个 key，但真实选举需要「抢成功 + 写入元数据 + 设置过期」三步原子执行。如果拆成多条命令，在网络分区或客户端崩溃时，可能留下无主但锁未释放、或 master 已切换但元数据不一致的状态。
典型错误现象：SET master:lock 12345 NX 成功后，紧接着 SET master:info '{"id":"12345","ts":171...}' 失败，导致锁存在但无有效元数据，后续节点无法安全判断谁是 master。
- 必须把「尝试加锁 + 写入身份 + 设置 TTL」打包进一个 Lua 脚本执行
- Redis 执行 Lua 是原子的，中间不会被其他命令插入
- 不能依赖
EVALSHA预加载（除非你严格管理脚本哈希一致性），首次推荐用EVAL
EVAL 脚本里怎么安全实现「抢占并写入」
核心逻辑：用 redis.call('SET', KEYS[1], ARGV[1], 'NX', 'PX', ARGV[2]) 一步完成带过期的 set；但注意——它只返回 OK/nil，不返回旧值，所以无法在失败时读取当前 master 信息。因此，更稳妥的做法是先 GET，再条件写入：
if redis.call('EXISTS', KEYS[1]) == 0 then
redis.call('SET', KEYS[1], ARGV[1], 'PX', ARGV[2])
redis.call('SET', KEYS[2], ARGV[3], 'PX', ARGV[2])
return 1
else
return 0
end
其中 KEYS[1] 是锁 key（如 master:lock），KEYS[2] 是元数据 key（如 master:info），ARGV[1] 是候选节点 ID，ARGV[2] 是 TTL 毫秒数，ARGV[3] 是序列化后的 info 字符串。
- 不要用
GETSET或SET ... GET：Redis 7.0+ 才支持后者，兼容性差 - TTL 必须显式传入（比如 30000），不能硬编码，便于测试调优
- 返回值建议用数字（1/0），客户端比对简单，避免字符串解析开销
客户端如何判断自己是否当选并维持心跳
当选不是一锤子买卖。节点抢到锁后，必须持续刷新 master:lock 和 master:info 的 TTL，否则超时会被其他节点顶替。这不是靠后台线程轮询，而是由选举脚本的「续期」分支处理：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
if redis.call('GET', KEYS[1]) == ARGV[1] then
redis.call('PEXPIRE', KEYS[1], ARGV[2])
redis.call('PEXPIRE', KEYS[2], ARGV[2])
return 2
else
return 0
end
客户端逻辑需分三阶段：
- 启动时执行「抢占脚本」：若返回 1 → 当选；返回 0 → 当前有主，去
GET master:info同步状态 - 当选后，启动独立 ticker（如每 10 秒一次），执行「续期脚本」：若返回 2 → 续期成功；返回 0 → 已被挤掉，立即降级为 follower
- 任何一次续期失败（网络超时、返回非 2），都应触发强制降级，不可重试掩盖
为什么 master:info 不能只存 ID，还得带时间戳和版本号
纯 ID 无法应对时钟漂移和脑裂场景。例如节点 A 抢到锁后宕机，TTL 过期，节点 B 接管；但 A 恢复后未清本地状态，仍认为自己是 master 并写数据——这时仅靠 GET master:lock 无法识别 A 是“过期 master”。
所以 master:info 应存类似 {"id":"node-b","ts":1718923456789,"epoch":12} 的结构：
-
ts（毫秒时间戳）用于检测“该 master 是否明显落后于当前时间”，客户端可拒绝服从明显滞后的 master -
epoch（单调递增整数）每次新选举 +1，follower 同步时只接受 epoch 更大的 info，天然防回滚 - 避免 JSON 序列化开销？可以，但得自行约定二进制格式；多数场景直接
SET master:info 'node-b|1718923456789|12'更省事
真正容易被忽略的是：所有读写 master:info 的地方，必须和锁 key 使用相同 key slot（比如都用 {master}:lock 和 {master}:info），否则集群模式下跨 slot 调用 Lua 会报 CROSSSLOT 错误。
