Redis问题总结

一、RedisTemplate过期时间问题 

1. Redis无论有没有设置expire，他都会遵循redis的配置好的删除机制，在配置文件里设置：内存不足时,数据会采取清除策略,默认为"volatile-lru"。

2. In Redis 2.6 or older the command returns -1 if the key does not exist or if the key exist but has no associated expire.

   Starting with Redis 2.8 the return value in case of error changed:

   The command returns -2 if the key does not exist.
   The command returns -1 if the key exists but has no associated expire.

3. 获取某一个Key的过期时间 

   Long expire = redisTemplate.opsForValue().getOperations().getExpire("key");

   返回key的多少秒后过期，而不是设置多长时间过期

二、Redis分布式锁

 1、加锁处理

 实际上就是在redis中，给Key键设置一个唯一值，为避免死锁，并给定一个过期时间。

SET lock_key random_value NX PX 5000

值得注意的是：
random_value 是客户端生成的唯一的字符串，释放锁会使用该值。
NX 代表只在键不存在时，才对键进行设置操作。
PX 5000 设置键的过期时间为5000毫秒。

2、释放锁

解锁的过程就是将Key键删除。但也不能乱删，不能说客户端1的请求将客户端2的锁给删除掉。这时候random_value的作用就体现出来。

为了保证解锁操作的原子性，我们用LUA脚本完成这一操作。先判断当前锁的字符串是否与传入的值相等，是的话就删除Key，解锁成功。

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0 
end

3、分布式锁带来的问题

这种实现方式有3大要点(也是面试概率非常高的地方):

1. set命令要用set key value px milliseconds nx;
2. value要具有唯一性;
3. 释放锁时要验证value值，不能误解锁;

事实上这类琐最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel、或者Redis Cluster保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况:

• 在Redis的master节点上拿到了锁;
• 但是这个加锁的key还没有同步到slave节点;
• master故障，发生故障转移，slave节点升级为master节点;其他线程获取该锁
• 导致锁丢失，这样就有二个线程获取到该锁。

不过这种不安全也仅仅是在主从发生 failover(故障转移)的情况下才会产生，而且持续时间极短，业务系统多数情况下可以容忍。

 业务上怎么处理分布式锁发生failover：如果在释放锁时，发现该锁对应的value值不一样，这说明发生了故障转移，记录一条数据（mysql、log都可以），然后在进行工单处理，不影响别的业务处理。