上一篇 <<<阿里云的Canal框架配置
下一篇 >>>Redis的调优设置
获取锁执行步骤：
1、获取当前时间
2、依次N个节点获取锁，并设置响应超时时间，防止单节点获取锁时间过长
3、锁有效时间=锁过期时间-获取锁耗费时间，如果第2步骤中获取成功的节点数大于
N/2+1,且锁有效时间大于0，则获得锁成功
4、若获得锁失败，则向所有节点释放锁
简单点说就是在锁过期时间内从半双以上的节点成功获取到了锁则说明获取锁成功。这个有点像注册中心的选举机制。
释放锁：
向所有节点发送释放命令即可
redlock的前提是所有节点时钟同步
redlock存在的问题
1、脑裂问题：就是多个客户端同时竞争同一把锁，最后全部失败。
比如有节点1、2、3、4、5，A、B、C同时竞争锁，A获得1、2,B获得3、4,C获得5,最后ABC都没有成功获得锁，没有获得半数以上的锁。官方的建议是尽量同时并发的向所有节点发送获取锁命令。客户端取得大部分Redis实例锁所花费的时间越短，脑裂出现的概率就会越低。
需要强调，当客户端从大多数Redis实例获取锁失败时，应该尽快地释放（部分）已经成功取到的锁，方便别的客户端去获取锁，假如释放锁失败了，就只能等待锁超时释放了
2、假设一共有5个Redis节点：A, B, C, D, E：
- client1锁住A、B、C,没有锁D、E
- C数据没有持久化就崩溃重启
- client2锁住了C、D、E，获取锁成功
解决方案：C崩溃后延时重启，延时时间大于锁的过期时间
3、假设一共有5个Redis节点：A, B, C, D, E：
- 客户端1从Redis节点A, B, C成功获取了锁（多数节点）。由于网络问题，与D和E通信失败。
- 节点C上的时钟发生了向前跳跃，导致它上面维护的锁快速过期。
- 客户端2从Redis节点C, D, E成功获取了同一个资源的锁（多数节点）。
- 客户端1和客户端2现在都认为自己持有了锁。
这种情况redis作者认为需要通过加强运维来避免
Martin提出的问题：
1、client1持有锁时，发生了阻塞并且阻塞时间超过了锁的过期时间，这时锁被释放了。
2、这时client2成功获取到了锁（这时相当于两个客户端同时持有了锁），提交了数据。
3、此时client1苏醒，又一次提交了数据。
解决方案，增加一个token-fencing：
1、增加一个递增的token,client1获取锁时同时得到一个token=33
2、当阻塞问题发生时，client2获取锁得到了token=34
3、提交数据时需要判断token大小，token小于上次提交的token就拒绝
相当于加了一把乐观锁（redis作者认为有了token其实就已经不再需要分布式锁了）
总结：
选用分布式锁时需要明确用途：
1、提升效率：避免一个任务被执行两次。但是就算执行了两次也不会出现致命问题
2、保证正确：一定要保证数据正确，不允许出现重复执行的情况
· 假如是为了提升效率而使用锁，则使用单机模式就足够了
· 假如是需要保证绝对的正确，redlock并不能达到目的。应该考虑类似Zookeeper的方案，或者支持事务的数据库。
推荐阅读：
<<<分布式缓存与本地缓存的区别
<<<Ehcache基础知识
<<<SpringBoot整合Ehcache
<<<Redis的5种数据类型
<<<Redis存放实体对象的方式及区别
<<<Redis的应用场景汇总
<<<Redis高效及线程安全的真正原因
<<<Redis为啥要分为16个库
<<<RDB和AOF持久化方式的区别
<<<Redis与数据库的一致性解决方案
<<<SpringBoot整合Redis的注解版本完成数据缓存
<<<Redis的淘汰策略
<<<Redis的事务操作（Mult和Watch）知识点
<<<Redis的过期机制使用场景示例
<<<Redis实现分布式锁的原理分析
<<<Redis分布式锁的实现代码示例
<<<使用Redisson工具实现分布式锁
<<<Redis集群模式之主从复制原理及存在的缺陷
<<<Redis集群模式之哨兵模式
<<<Redis集群模式之Cluster去中心化分片集群
<<<Linux环境下安装单机Redis
<<<Redis Cluster集群环境搭建
<<<Redis Cluster如何动态扩容与缩容
<<<Redis Cluster主从节点自动切换
<<<Redis集群模式的类型和缺陷汇总
<<<Redis缓存的穿透、击穿和雪崩效应
<<<Redis解决穿透击穿问题时使用的布隆过滤器知识点
<<<Redis与MySQL的数据同步解决方案
<<<阿里云的Canal框架实现Redis与Mysql同步原理及代码示例
<<<阿里云的Canal框架配置
<<<Redis的调优设置
<<<Redis常见问题汇总
