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

一、分布锁

 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指令没有及时同步给从库，就会出现主从数据不一致的情况。