spring boot 和redis集成

图解分析：基于setnx的分布式锁有什么缺陷？

基于setnx的分布式锁存在单点风险，如果存储的分布式锁key挂掉的话，就可能存在丢锁的风险。一旦丢锁，就会造成多个客户端同时握有锁，从而导致分布式锁失败。
具体如下：

1. 客户端A 从master拿到锁lock01
2. master正要把lock01同步(Redis的主从同步通常是异步的）给slave时，突然宕机了，导致lock01没同步给slave
3. 主从切换，slave节点被晋级为master节点
4. 客户端B到master拿lock01照样能拿到。这样必将导致同一把锁被多人使用。

以上这种情况，无论Redis的部署架构是单机模式、主从模式、哨兵模式还是集群模式，都存在这种风险。
那怎么解决呢？Redis 之父 antirez 提出了 redisson的redlock算法 可以解决这个问题。

redlock算法的设计原理

redlock为了解决CAP的cp,数据一致性，采用有n个redis节点，n为奇数，上图我们有3个master，这3个master完全独立，不是主从复制或集群。（这里和zookeeper类似，熟悉zookeeper的同学或听过我课程的同学都能懂）

为什么N必须为奇数呢？
在回答这个问题前，先给大家讲一下什么是容错？
即在集群环境中，失败实例多少个我还是可以容忍，即系统的CP还是数据一致的。
例如
在集群环境中，redis失败1台，我还是可以容忍， 2n+1=2+1=3， 故部署奇数为3台redis 实例， 所以在3台的集群中，死掉1台，剩下2台集群正常工作。
在集群环境中，redis失败2台，我还是可以容忍， 2n+1=2*2+1=5，故部署奇数为5台redis 实例， 所以在5台的集群中，死掉2台，剩下3台集群正常工作。

那为什么是奇数，不是偶数？
因为有一个原则：使用资源最少，产生最大的容错。
例如
在集群环境中，redis失败1台，我还是可以容忍；奇数= 2n+1=2+1=3，偶数=2n+2=4
在集群环境中，redis失败2台，我还是可以容忍；奇数= 2n+1=2*2+1=5，偶数=2n+2=6
以上容忍度一样，但是部署的实例偶数比奇数多了一台。