本质是主从数据复制延迟与锁生命周期不匹配，导致互斥失效；须强制读写主节点、设冗余过期时间（业务P99耗时×2+≥500ms缓冲）、禁用从节点锁校验，改用心跳探活，中长期升级Redlock或多活集群。

高并发双机热备集群下，分布式锁因同步时延出现“毛刺”（即短暂的互斥失效、重复执行、锁误释放等异常），本质是主从数据复制延迟与锁生命周期不匹配导致的。关键不在“有没有备份”，而在“锁状态能否被所有节点实时、一致地感知”。

主从复制延迟直接破坏锁的互斥性

双机热备通常采用 Redis 主从 + 哨兵模式，但主节点写入锁后，从节点同步存在毫秒级延迟（尤其在高负载或网络抖动时）。此时若读请求路由到从节点做锁校验（如判断锁是否存在、检查 value 是否匹配），可能读到过期或旧状态，造成：
– 本该拒绝的加锁请求被误放行
– 本该续期的锁被判定为“已丢失”而放弃续约
– 释放锁时因从节点未同步最新 value，Lua 脚本验证失败

强制读主 + 过期时间冗余设计

避免从节点参与锁核心流程，所有加锁、续期、释放操作必须直连主节点（通过哨兵自动发现当前主节点地址）。同时将锁过期时间设为：
– 业务最长预期耗时 × 2
– 再叠加一个“安全缓冲窗口”（建议 ≥ 500ms）
例如：业务 P99 耗时 800ms，则锁过期设为 2200ms。这样即使主从同步延迟达 300ms，锁仍保有足够余量维持有效状态。

禁用从节点锁校验，改用心跳探活替代

不要让任何服务去从节点查锁——这是毛刺的主要来源。若需快速感知锁持有状态（如监控或降级判断），可由持有锁的服务主动向共享存储（如 Redis 主节点本身或独立 etcd）写入带 TTL 的心跳 key（如 lock:order_123:holder），其他服务只读该 key 判断活跃性，而非读锁 key 本身。心跳 TTL 应略短于锁过期时间（如锁 2200ms，心跳设 2000ms），并由 Watch Dog 线程持续刷新。

升级为 Redlock 或多活集群（中长期方案）

双机热备本质仍是单点锁源，无法根治时延毛刺。生产环境建议：
– 小规模集群：采用 Redlock（至少 3 个独立 Redis 实例），要求多数派（≥ N/2+1）写成功才视为加锁成功，天然容忍单节点延迟或故障
– 中大规模：迁移到 Redis Cluster 模式，并确保锁 key 的 slot 固定（如用 {order_123} 强制哈希到同一分片），配合客户端重试与幂等防护
– 对一致性要求极高的场景（如金融扣款），应结合数据库行锁 + 版本号作为最终兜底，Redis 锁仅作前置快速拦截