如果追求高可用性（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",KEYS[1]) == ARGV[1]
then
return redis.call("DEL",KEYS[1])
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主服务器的系统时间一致性
