分布式锁

分布式锁

• 资源
• 互斥
• 可用

墙上时间

有效租期

• session的有效时间，client 一定比server小， 由client 主动发起续租，避免机器之间时间漂移 而无法严格对对齐的问题

切换时间

• client 与server 的HB 间隔比较长，带来的问题是 client 因故障没有主动释放锁，那其它的锁竞争者(client) 只能等到 session 超时才会重新抢锁。在一些应用场景下对服务可用性有不小的不利影响。
• 反之，虽然锁切换时间变短，但对于server 会产生较大的压力，也可能因网络短时间抖动导致锁的丢失。

多系统的协作

存在这种场景：

• client a 持有锁，在时间T0因某种原因(如著名的JavaGC) hang，导致锁已丢失，且client a 业务层还没有感知，继续在T1时间对服务S进行写操作(W)。
• client b 在T0.6时抢到锁，在T0.8执行W。
• 这种情况下，a 在T1的W 其实是非法的(导致的问题如写坏数据)
  解决这种情况，分布式锁服务可以把session id 做成严格自增，或者生一个严格自增的token，client W时带入S，S拒绝掉小的id/token。 方案来自于Martin Kleppmann.
  

ref

• How to do distributed locking
• Is Redlock safe