Redis 分布式锁

如果追求高可用性（AP） 就采用redis

如果追求高一致性(CP) 就采用zookeeper

加锁方式:set lockKey uniqueId NX PX expireTime

• lockKey可以根据业务自己定义（如订单）
• uniqueId是为了不解错锁（uniqueId可以是session Id 或者线程Id等）

怎么会解错锁？举个小案例吧

S1 获得Lock，ttl时间5s，实际执行了7s

S2 获得Lock，ttl时间5s，实际执行了4s

如果没有uniqueId S1在第7s的时候解锁，或解了S2的锁

• NX代表当前不存在锁的时候才能加锁成功
• PX 毫秒过期时间，如果是秒就用ES

解锁方式:通过lua脚本实现原子操作，先进行uniqueId对比操作，如果相同，则执行del解锁操作

if redis.call("GET",KEYS1) == ARGV1

then

return redis.call("DEL",KEYS1)

else

return 0

end

续期:当分布式锁到达了超时时间，但是业务并没有完成，则将对锁进行续期

• S1 获得Lock，ttl时间5s，实际执行了7s，如果没有续期那么S1后2秒就没有锁

续期的两种方式：

• 开启一个后台守护线程，每隔3秒对key设置ttl时间5S进行续期，当主线程执行完操作之后，对key进行解锁，那么守护进行也随之消亡
• 采用异步任务，获得锁后，把所有锁的线程放到一个Map里，然后每隔几秒进行轮询，如果客户端还持有锁（即Map中还存在），就延长ttl时间

RedLock算法对应的场景 主节点挂掉后，lockkey还未同步到从节点，导致从节点上没有lockkey（发生概率很小，面试官喜欢在AP模型里解决CP模型的问题）

• 对3个完全独立的redis主服务器一次获得锁（一般要基数个，为了少数服从多数）
• 如图请求时间4000-1000=3s小于TTL时间5s,并且至少有半数（大于2个）获得锁，才算真正获得锁

缺点（已废弃，不常用，因此只学习算法思想）

• 复杂度高，需要设计一些算法去实现
• 不可靠，如果redis主服务器宕机，会影响到锁的使用（即少数服从多数会受影响）
• 性能瓶颈，需要访问多个redis实例

• 另外最要命的是还需要求所有redis主服务器的系统时间一致性