Redis - 扩展 - 分布式锁 与过期策略

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zanpengfei/article/details/85834691

一、分布锁

 1、setnx 和 expire 组合在一起的原子指令来解决分布式锁,但这种方式是有缺陷的,不太安全的,例如Sentinel集群,当客户端向主节点申请分布式锁成功后,主节点还没来及向从节点同步时,主节点挂掉了,主从切换,某个从节点摇身一变成为主节点,第二个用户再次申请锁,是可以成功的,这样俩个用户成功申请到了2把锁,不安全因素产生了,解决该方案是通过Redlock算法。

2、如果要使用redlock,需要提供多个Redis实例,这些实例相互独立没有主从关系,同很多分布式算法相同,redlock也使用了大多数机制。

       加锁时,它会向过半节点发送 set(key, value, nx=True, ex=xxx) 指令,只要过半节点 set 成功,那就认为加锁成功。释放锁时,需要向所有节点发送 del 指令。不过 Redlock 算法还需要考虑出错重试、时钟漂移等很多细节问题,同时因为 Redlock 需要向多个节点进行读写,意味着相比单实例 Redis 性能会下降一些。   

二、过期策略

1、Redis将所设置过期key都放到一个独立的字典中。过期key处理的方式。

1)定期扫描:因为Redis将过期key都放到独立的字典中,所以可以定期扫描该字典,发现过期则删除;但是过期扫描不会扫描所有的key,而是采用贪心策略,策略如下首先从过期字典中随机 20 个 key,然后删除这 20 个 key 中已经过期的 key,最后如果过期的 key 比率超过 1/4,那就重复步骤 1。

注意:批量key的过期时间不要太集中,分散过期处理的压力。

2)惰性策略删除过期key:客户端访问这个key时,Redis检查是否过期,过期则删除。

2、从库的过期策略

       从库不会定期扫描,完全是根据主库在AOP文件中记录的del指令来操作的,因为指令是异步的,如果主库key的del指令没有及时同步给从库,就会出现主从数据不一致的情况。

猜你喜欢

转载自blog.csdn.net/zanpengfei/article/details/85834691