多节点异步系统：分布式Lease与Lock谁更适配崩溃安全场景？

我正在为基于Quarkus + Hazelcast的多节点分布式系统实现crash-fault tolerance (CFT)，用于协调DataSource缓存刷新，需要在两种协调机制间选型并明确其权衡点。

故障场景 #

场景1：刷新期间硬崩溃 #

Node A: starts refresh → partial update possible → CRASH
Node B: sees "unknown state" → either waits forever OR starts too (overlap risk)

场景2：刷新任务阻塞但进程存活（FLP问题） #

Node A: starts refresh → task STUCK (process alive)
Node B: sees A alive → does nothing → blocked forever

可选防护方案 #

方案A：基于Lease的锁（带自动过期TTL） #

Node A: acquire(lease, ttl=60s) → start async refresh task → CRASH
Node B: waits 60s → lease auto-expires → acquire(lease) → refresh

方案B：Lock + 显式故障检测 #

Node A: lock() → start async refresh task → CRASH
Node B: detects Node A dead → forceUnlock() → lock() → refresh

方案选型结论 #

方案A更适合你的场景，原因如下：

• 适配FLP问题场景：方案B的显式故障检测只能识别节点死亡，但对场景2中「进程存活但任务阻塞」的情况无能为力——Node B会一直认为Node A存活，导致系统永久阻塞。而方案A的TTL机制不管进程是否存活，只要任务超时未完成，锁就会自动释放，避免了FLP问题带来的永久阻塞风险。
• Hazelcast原生支持更友好：Hazelcast本身提供了带TTL的分布式锁（ILock支持lock(long leaseTime, TimeUnit unit)），无需额外开发故障检测逻辑，实现成本更低，且与Quarkus的集成更顺滑。
• 避免强制解锁的风险：方案B的forceUnlock()操作需要额外的权限校验和状态判断，若故障检测逻辑存在误判，可能导致正常执行的刷新任务被强制中断，引发缓存数据不一致；而方案A的TTL过期是基于时间的被动释放，只要TTL设置合理（略大于正常刷新任务的执行时间），就能有效避免这种误操作风险。
• 简化状态协调：方案A无需维护节点存活状态的同步，仅依赖锁的TTL机制，减少了分布式系统中状态同步的复杂度，降低了潜在的一致性问题。

当然方案A也有需要注意的点：TTL的设置需要精准评估——如果TTL过短，可能导致正常刷新任务未完成就释放锁，引发重复刷新；如果TTL过长，在节点崩溃时会延长系统恢复时间。可以通过监控刷新任务的平均执行时间，设置略大于99分位执行时间的TTL来平衡。

内容的提问来源于stack exchange，提问作者ProtectorRTD