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深度历险--核心原理与应用实践》

热门相关:奉旨成婚:悍妃训夜王   狂仙   废材逆袭:冰山王爷倾城妃   妻子的情人   弃妃不承欢:腹黑国师别乱撩