在使用redis来实现分布式锁的时候，如果redis是集群的，比如1主4从，这种主从模式就会存在延迟问题，导致加锁出现问题。

此时就应该使用红锁的方案，即在代码中不依赖于主从，将这5台机器视为平等的，在代码中依次对这5台机器去加锁，只有成功的机器数大于一半就算加锁成功，其他机器也就没必要再去操作了，相反，如果大于一半的机器失败了，就算失败，其他机器也就没必要再去操作了。

由于是遍历操作这5台机器，也就不用关心有没有机器挂掉了，因为挂掉了自然算加锁失败。红锁方案要求机器数为奇数。而且从原理上来看，每一个请求都会从前往后的顺序依次去操作这些机器，而不是乱序的，也就不会出现死锁的问题。

为什么叫红锁？
因为这个方案是redis创始人发明的，本应该叫 Redis Lock，但是简写成 RedLock。

问题1：
请求1依次加锁1，2，3成功，算成功，不巧此时机器3没了，数据也丢了，然而运维手速很快，立马搞了台新机器6放在了3的位置上，显然6里面并没有加锁的key，如果此时请求2来加锁，1错，2错，3对，4对，5对；显然就加锁成功了，于是就出现了并发问题了，这种情况呢，只能在运维手册里写明，这5台机器，要特殊对待，延迟一段时间再去部署，通过人为来把控。