【Redis】Redis 典型应用 - 分布式锁原理与实现

Redis 典型应⽤ - 分布式锁

什么是分布式锁

在⼀个分布式的系统中， 也会涉及到多个节点访问同⼀个公共资源的情况。此时就需要通过 锁 来做互斥控制， 避免出现类似于 “线程安全” 的问题

线程安全问题：多个线程并发执行的时候，执行先后顺序是不确定的。就需要保证程序在任意执行顺序下执行逻辑都是OK的

⽽ Java 的 synchronized 或者 C++ 的 std::mutex， 这样的锁都是只能在当前进程中⽣效， 在分布式的这种多个进程多个主机的场景下就⽆能为⼒了。

此时就需要使⽤到分布式锁。

本质上就是使⽤⼀个公共的服务器， 来记录 加锁状态

这个公共的服务器可以是 Redis， 也可以是其他组件(⽐如 MySQL 或者 ZooKeeper 等)， 还可以是我们⾃⼰写的⼀个服务

分布式锁的基础实现

思路⾮常简单，本质上就是通过⼀个键值对来标识锁的状态

举个例⼦：考虑买票的场景， 现在⻋站提供了若⼲个⻋次， 每个⻋次的票数都是固定的

现在存在多个服务器节点， 都可能需要处理这个买票的逻辑：先查询指定⻋次的余票， 如果余票 > 0， 则设置余票值 -= 1

显然上述的场景是存在 “线程安全” 问题的， 需要使⽤锁来控制

否则就可能出现 “超卖” 的情况

此时如何进⾏加锁呢？我们可以在上述架构中引⼊⼀个 Redis，作为分布式锁的管理器

此时， 如果 买票服务器1 尝试买票， 就需要先访问 Redis， 在 Redis 上设置⼀个键值对。⽐如 key 就是⻋次， value 随便设置个值 (⽐如 1)

如果这个操作设置成功， 就视为当前没有节点对该 001 ⻋次加锁， 就可以进⾏数据库的读写操作。操作完成之后， 再把 Redis 上刚才的这个键值对给删除掉

如果在 买票服务器1 操作数据库的过程中， 买票服务器2 也想买票， 也会尝试给 Redis 上写⼀个键值对，key 同样是⻋次。但是此时设置的时候发现该⻋次的 key 已经存在了， 则认为已经有其他服务器正在持有锁， 此时 服务器2 就需要等待或者暂时放弃

Redis 中提供了 setnx 操作， 正好适合这个场景。即：key 不存在就设置， 存在则直接失败

但是上述⽅案并不完整

某个服务器加锁成功了（setnx 成功），执行后续逻辑过程中，程序崩溃了（没有执行到解锁）

这里不能通过在 finally 的方式解锁，这只是对进程内的锁有效，这对分布式系统的无效的，比如服务器直接断电，进程就直接异常终止了

引⼊过期时间

当 服务器1 加锁之后， 开始处理买票的过程中， 如果 服务器1 意外宕机了， 就会导致解锁操作 (删除该key) 不能执⾏。就可能引起其他服务器始终⽆法获取到锁的情况

为了解决这个问题， 可以在设置 key 的同时引⼊过期时间。即这个锁最多持有多久，就应该被释放

可以使⽤ set ex nx 的⽅式， 在设置锁的同时把过期时间设置进去

注意! 此处的过期时间只能使⽤⼀个命令的⽅式设置