redlock实现原理

Redlock算法

我们应该使用多个Redis,这些节点是完全独立的，不需要使用复制或者任何协调数据的系统，多个redis系统获取锁的过程就变成了如下步骤：

以毫秒为单位获取当前的服务器时间
尝试使用相同的key和随机值来获取锁，对每一个机器获取锁时都应该有一个超时时间，比如锁的过期时间为10s那么获取单个节点锁的超时时间就应该为5到50毫秒左右，他这样做的目的是为了保证客户端与故障的机器连接，耗费多余的时间！超时间时间内未获取数据就放弃该节点，从而去下一个节点获取，直至将所有节点全部获取一遍！
获取完成后，获取当前时间减去步骤一获取的时间，当且仅当客户端半数以上获取成功且获取锁的时间小于锁额超时时间，则证明该锁生效！
获取锁之后，锁的超时时间等于设置的有效时间-获取锁花费的时间
如果 获取锁的机器不满足半数以上，或者锁的超时时间计算完毕后为负数 等异常操作，则系统会尝试解锁所有实例，即使有些实例没有获取锁成功，依旧会被尝试解锁！
释放锁，只需在所有实例中释放锁，无论客户端是否认为它能够成功锁定给定的实例。

redlock缺点：

1. 时钟回拨。
   client1获取锁后，某一个节点时钟回拨了，导致该redis节点提前过期了，
   client2 获取锁

2. 业务执行时间过长，比如发生了full gc，此时锁过期了，其他也能获取锁。线程不安全。

客户端1长时间被挂起后，客户端2获取到锁，开始写库操作，同时携带令牌 34,写库完成后，客户端1苏醒，开始进行入库操作，但是因为携带的令牌为33 小于最新令牌，该次提交就被拒绝！
这个想法听起来似乎是很完备的思路，这样即使系统因为某些原因被挂起，数据也能够被正确的处理。但是仔细想一下：
如果仅当您的令牌大于所有过去的令牌时，数据存储区才能始终接受写入，则它是可线性化的存储区，相当于使用数据库来实现一个 分布式锁系统，那么RedLock的作用就变得微乎其微！甚至不再需要使用redis保证分布式锁！

如何解决？

通过程序弥补这些可能差错，
对分布式锁有一定宽容度或者说容错，即使同时操作了同一份数据，也能保证对结果没什么影响，
比如允许极端情况下的并发存在，数据层面可以使用乐观锁，数据做到幂等性处理。

参考学习链接