关于Redis分布式锁和Zookeeper锁的小结

一 为什么需要分布式锁?

我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。

如果换做是多个进程，需要同时操作一个共享资源，如何互斥呢？

例如，现在的业务应用通常都是微服务架构，这也意味着一个应用会部署多个进程，那这多个进程如果需要修改 MySQL 中的同一行记录时，为了避免操作乱序导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。

想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」。

而这个外部系统，必须要实现「互斥」的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。

这个外部系统，可以是 MySQL，也可以是 Redis 或 Zookeeper。但为了追求更好的性能，我们通常会选择使用 Redis 或 Zookeeper 来做。

二 Redis如何正确加锁 避免死锁或者被别人释放

1.如何避免死锁?

可以给锁加上一个过期时间

2.如何避免被别人释放?

加锁的时候设置上一个唯一标识，可以是线程的ID也可以是UUID

这时候就出现一个问题，还没有操作完，锁被释放了怎么办？

可以在加锁时，先设置一个过期时间，然后我们开启一个「守护线程」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。

已经有一个库把这些工作都封装好了：Redisson。

这时候流程就变成了

我们在使用 Redis 时，一般会采用主从集群 + 哨兵的模式部署
当主库异常宕机时，哨兵可以实现「故障自动切换」，把从库提升为主库，继续提供服务，以此保证可用性。

还有一种模式RedLock红锁

舍弃Redis的主从和哨兵机制

Redis 作者提出的 Redlock 方案，是如何解决主从切换后，锁失效问题的。
Redlock 的方案基于 2 个前提：

1.不再需要部署从库和哨兵实例，只部署主库
2.但主库要部署多个，官方推荐至少 5 个实例

整体的流程是这样的，一共分为 5 步：

1.客户端先获取「当前时间戳T1」

2.客户端依次向这 5 个 Redis 实例发起加锁请求（用前面讲到的 SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁

3.如果客户端从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败

4.加锁成功，去操作共享资源（例如修改 MySQL 某一行，或发起一个 API 请求）

5.加锁失败，向「全部节点」发起释放锁请求（前面讲到的 Lua 脚本释放锁）

Zookeeper，基于它实现的分布式锁是这样的：

1.客户端 1 和 2 都尝试创建「临时节点」，例如 /lock

2.假设客户端 1 先到达，则加锁成功，客户端 2 加锁失败

3.客户端 1 操作共享资源

4.客户端 1 删除 /lock 节点，释放锁

Zookeeper 的优点：

不需要考虑锁的过期时间

watch 机制，加锁失败，可以 watch 等待锁释放，实现乐观锁

但它的劣势是：

性能不如 Redis

部署和运维成本高

客户端与 Zookeeper 的长时间失联，锁被释放问题

原文: https://mp.weixin.qq.com/s/ybiN5Q89wI0CnLURGUz4vw