Redis基础知识（学习笔记3--Redlock）
讨论的问题：Redis 主从架构锁失效（丢失）
1.背景描述
当主节点挂掉时，从节点会取而代之，但是客户端却没有明显感知。比如，原先第一个客户端在主节点中成功申请了一把锁，但是这把锁还没来得及同步到从节点，主节点突然挂掉了，然后从节点变成了主节点，这个新的主节点内部没有这个锁，所以当另一个客户端发送请求加锁时，立即就批准了。这样就会导致系统中同样一把锁被两个客户端同时持有，不安全性由此产生。
问题示意图如下：
即使在Sentinel集群下，此问题依然存在。
此问题在主从failover时才会发生，并且持续时间会很短，很多时候，对业务无明显影响。
2. Redlock方案 Redlock实现原理
Redlock方案，需要多个Redis示例，这些示例之间相互独立，没有主从关系。通很多分布式算法一样，Redlock也使用“大多数机制”。
3.redlock-py----Realock算法
import redlock addrs = [{ "host" : "localhost", "port" : 6379, "db" : 0 }, { "host" : "localhost", "port" : 6479, "db" : 0 }, { "host" : "localhost", "port" : 6579, "db" : 0 }] dlm = redlock.Redlock(addrs) sucess = dlm.lock("user-lck", 5000) if sucess: print 'lock sucess' dlm.unlock('user-lck') else: print 'lock failed'
加锁时，它会向过半节点发送set(key, value, nx=True, ex=xxx) 指令，只要过半节点set成功，就认为加锁成功。释放锁时，需要向所有节点发送del指令。
生产过程，还需要考虑出错重试、时钟漂移等细节问题。
4.坏处
（1）需要多台Redis实例；
（2）因为Redlock需要向多个节点进行读写，意味着其相比单实例Redis的性能会下降。
特别是，当某一个节点挂掉，其成功写入的返回时间明显加大了。这是要特别消失程序对写入redis超时时间的设置。（即redis还在写入，但是redis客户端已经认为写入超时了）。
（3）极端情况，Redis故障或重启，可能导致锁丢失。
例如，Redis实例 其将数据fsync到磁盘的策略为【appendfsync everysec 即每秒fsync一次】，即在故障时，可能会丢失1秒钟数据。
此时有A实例；B实例；C实例。
client请求，将数据写入到了A实例和B实例了，C未写入，并且A已经fsync磁盘了，B尚未fsync到磁盘。但是很不巧，B故障了，或重启了，那么B的数据丢失了。
这个时候，如果有新的请求，那么B和C可能接收-设置同样的key，这时候，对B而言，就像前面的key没有出现过一样，它忘记了。此时就可能出现“超卖”的问题。
当然，在【appendfsync always: 每次有新命令追加到AOF文件时，就执行一次fsync】,就不会出现重启，丢命令了。但是安全代码的成本就是慢和高消耗。
学习参阅声明
《Redis深度历险--核心原理与应用实践》