【HBZ分享】Redis之红锁Redlock---主从在同步锁信息时恰好宕机导致没同步到从库锁的信息，从库顶替上之后会有两个线程加同一把锁问题

Redlock实现流程

1. 至少3台服务器，通常来说Redis节点个数是单数，因为检测通过是2N+1台通过即可，偶数会浪费一台
2. 这3台服务器相互独立，没有任何主从或者集群关系
3. 当加锁时会同时将锁信息写入3台服务器中
4. 当触发锁机制时，会同时向3台服务器请求锁，当3台中有2台以上的服务器查到了锁已被占用，则就会获取锁失败，就会认为有锁了， 这样即使其中有一台服务器宕机了，也不会有影响，因为剩余两台只要正常，那就会检测通过

Redlock解决的问题（实际使用率并不高）

1. 加入主从架构中，主库获取了锁信息，但如果此时还没来得及同步给从库，主库就宕机了，导致从库没有该加锁信息。当从库顶替主库后，第二个线程又来申请锁，但由于没有同步到从库，所以从库没有锁信息，会误认为可以获取锁，但实际已经有一条线程把锁申请走了，这就出现了问题，此时Redlock就派上了用场，他就是解决这个问题的

允许宕机台数设计的计算方式（2N + 1， N表示允许宕机的节点个数）

1. 如果允许1台服务器宕机，即要准备2 * 1 + 1 = 3台， 即有2台通过即可完成检测， 允许宕机1台
2. 如果允许2台服务器宕机，即要准备2 * 2 + 1 = 5台， 即有3台通过即可完成检测， 允许宕机2台
3. 如果允许3台服务器宕机，即要准备2 * 3 + 1 = 7台， 即有4台通过即可完成检测， 允许宕机3台

通过机制的计算方式(N / 2 + 1)

1. 当有3台服务器时，则有3 / 2 + 1 = 2台 通过即可， 只允许宕机1台
2. 当有5台服务器时，则有5 / 2 + 1 = 3台 通过即可， 只允许宕机2台
3. 当有7台服务器时，则有7 / 2 + 1 = 4台 通过即可， 只允许宕机3台</