redis分布式锁演进与分布式锁拓展

redis 分布式锁实现

基础的k-v形式

setnx key value
expire key time 

如果出现大量锁竞争怎么办？

需要可等待

出现被别人释放的情况

不能被别人释放

如果相同线程多个地方加锁怎么解决

需要可重入

使用setnx之后服务挂了，没有设置过期时间，导致死锁怎么办

需要原子性

在设置的释放时间内没有执行完，出现并发问题怎么办？

需要可续期 watch dog

redisson 如何实现的watch dog ，使用redisson遇到哪些问题？

在获取锁之后，master挂了会怎么样，怎么办？

主从切换，可能导致多个获取锁

redis 提出了redlock算法解决这个问题

• 需要半数以上的master节点

为了获取锁，客户端执行以下操作：

它以毫秒为单位获取当前时间。
它尝试在所有N个实例中依次使用所有实例中相同的键名和随机值来获取锁定。在第2步中，在每个实例中设置锁时，客户端使用的超时时间小于总锁自动释放时间，以便获取该超时时间。例如，如果自动释放时间为10秒，则超时时间可能在5到50毫秒之间。这样可以防止客户端长时间与处于故障状态的Redis节点通信时保持阻塞：如果一个实例不可用，我们应该尝试与下一个实例尽快通信。
客户端通过从当前时间中减去在步骤1中获得的时间戳，来计算获取锁所花费的时间。 ，并且获取锁所花费的总时间小于锁有效时间，则认为已获取锁。
如果获取了锁，则将其有效时间视为初始有效时间减去经过的时间，如步骤3中所计算。
如果客户端由于某种原因（无法锁定N / 2 + 1实例或有效时间为负数）而未能获得该锁，它将尝试解锁所有实例（即使它认为不是该实例）能够锁定）。

但是它需要部署2n+1个master，不然会产生脑裂问题

因为CAP理论，redis仅支持ap ， 可用性与分区容错性，如果需要CP则应该使用zk，zk牺牲了可用性

https://redis.io/topics/distlock

对比

利用数据库自身提供的锁机制实现，要求数据库支持行级锁；实现简单，稳定可靠；性能差，无法适应高并发场景；容易出现死锁的情况；无法优雅的实现阻塞式锁；只能基于数据表的锁，无法达到代码级的锁，不够灵活；

redis 性能好；使用redisson 也相对简单，但是引入第三方中间件增加风险；不能保证强一致性；
zk 基于zk的节点特性以及watch机制实现（临时顺序节点）；框架Curator；性能好；可靠性高，能较好的实现阻塞式锁；能保证加锁的一致性，但是选举过程中集群不可用；