分布式锁原理及代码实现

引言

一般我们在单进程的多线程环境中，使用锁来保证多个线程对临界资源的排他性访问。也就是同一时刻，同一任务只能在一个线程中运行。

锁：

• 互斥锁、自旋锁（互斥类型的锁）
• 读写锁（对应到数据库中的行锁，读锁叫做共享锁、写锁叫做排它锁，应用在多读少写的场景）
• 信号量、条件变量 （他们是同步类型的锁，也就是用来实现同步，当然也能实现互斥锁）sem_init、sem_post（++）、sem_wait（–）信号量的第二个参数pshared==0，用在多线程，>>0用在多进程通信（IPC：Pipe FIFO 信号量、信号、共享内存、消息队列、socket）
• 无所编程：原子变量和内存屏障

一、分布式锁的目标、解决了什么问题？

目标：在分布式场景下，实现互斥类型的锁。

作用：解决分布式事务中的隔离性问题。

这么说可能有点抽象，别着急，继续往下看，慢慢就理解了。

1.2 单进程多线程场景下的互斥锁

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; // 初始化mutex
pthread_mutex_lock(&mutex); // 加锁
/* 这里是对临界资源的操作 */
pthread_mutex_unlock(&mutex);  // 解锁

多线程的锁迁移到分布式环境下，即同一时刻，只允许一个实例执行某种操作。

S1~S4是分布在不同机器的具有同样功能的程序。每个程序在执行某项操作前需要先获取锁，只有成功拿到锁才能执行后续的操作。

1.2 思考：

1. 因为锁本身也是一种资源，而且需要让不同机器中的实例都要能访问的到（通过网络交互访问），可以考虑将锁资源保存在Mysql或者Redis中，具体如何保存文章后面会再详细展开。
2. 行为：分为加锁和解锁。加解锁的本质是进行一次网络交互。某个实例加锁成功，其他实例加锁失败；只有持有锁的实例释放锁，其他实例才能获取锁。注意：加锁对象和解锁对象必须为同一个。

说明：在单进程多线程的场景下，锁资源是每个线程都能访问的，而且锁资源及行为是同生共死的，锁挂掉，也就不存在所谓的加锁和解锁了。

二、分布式锁的特性

• 互斥性（同一时刻，只允许一个实例获取锁并执行某种操作）
  
• 锁超时（假设S1某一时刻获取了锁，但是S1挂掉了，如果没有锁超时机制，其他实例永远不可能获取到锁，需要有一个最大时长，到时需要主动释放锁）
  
• 可用性（合理的时间内得到合理的回复）
  可用性在实现上有两种类型：
  1.存储型，存储了某类资源或者数据，如锁，假设保存锁资源的实例挂掉了，也要有与其状态一致或者接近的实例顶上；如：redis的哨兵模式，但是低效一般不用，使用raft一致性算法，半数以上即可，假设更新数据，需要半数以上的节点都更新后，返回更新成功。需要实现：多备份和故障切换。。
  2.计算型，比如多个网关的实例，不进行存储，只进行计算分发请求.实现：开多个备份点即可
  
• 容错性（存储锁资源的实例挂掉，顶替上来的实例若是没有之前申请的锁，就会出现锁失效）
  实现：一般用一致性来解决（半数以上同意）：1. 严格的raft一致性算法；2. redlock。
  

三、分布式锁类型

1. 重入锁和非重入锁
   重入锁: 已经获取锁的对象可以再次获取锁，重入锁对应到多线程就是递归锁。
   非重入锁: 已经获取锁的对象不能再次获取锁。
   
2. 公平锁和非公平锁
   公平锁对应互斥锁，非公平锁对应自旋锁。
   

3.1 互斥锁和自旋锁的区别

线程1在获取到锁之后，其他线程在干什么？

如果是互斥锁，其他线程会阻塞，被加入到阻塞队列，当该互斥锁释放后，会从阻塞队列取出加入到就绪队列，等待CPU执行。

如果是自旋锁，其他线程会被直接加入到就绪队列，等待CPU执行。（自旋锁底层实现是原子操作，CAS一直主动轮询，获取失败就shced_yield让出CPU）

**补充：操作系统时间片到了也会加入到就绪队列。**就绪队列的优点在于，如果CPU某个核心空闲了，就会去就绪队列去任务执行。

小结：互斥锁因为被加入到阻塞队列，然后按照顺序依次加入到就绪队列，每个线程都有机会获取锁，所以互斥锁是公平锁，而自旋锁，因为是直接加入到就绪队列的，开始争抢CPU，所以是非公平锁。

四、分布式锁实现的重点

1. 锁也是一种资源，需要存储；要保证可用性，避免锁失效
2. 互斥语义：给锁打上标记
3. 加锁和解锁对象必须为同一个
4. 加锁解锁是网络通信
5. 需要实现锁超时（超时时间需要远远大于一次网络交互的时间）
6. 如何知道锁已被释放：a) 主动探寻，也就是非公平锁；b) 被动通知（广播通知：非公平锁；排队通知：公平锁）
7. 是否支持同一持锁对象继续加锁（重入锁和非重入锁）

五、分布式锁的两种实现

5.1 Mysql数据库实现

思路：主要用唯一键的唯一性约束来实现互斥性

我们现在创建一张表dislock，它的表结构如下：

DROP TABLE IF EXISTS `dislock`;
CREATE TABLE `dislock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `lock_type` varchar(64) NOT NULL COMMENT '锁类型',
  `owner_id` varchar(255) NOT NULL COMMENT '持锁对象',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_lock_type` (`lock_type`) 
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT
CHARSET=utf8 COMMENT='分布式锁表';

加锁

假设S1加锁成功，也就是往表dislock中成功插入一条记录。其中：act_lock是具体的锁，ad2daf3是S1的id。

INSERT INTO dislock (`lock_type`, `owner_id`) VALUES ('act_lock', 'ad2daf3');

解锁

假设S1解锁，也就是从表中删除对应的记录。要表明解什么锁，谁来解（带上自己的id），如果id不一致解锁失败。

DELETE FROM dislock WHERE `lock_type` = 'act_lock' AND `owner_id` = 'ad2daf3';

假设在S1加锁成功后，还没解锁。S2此时也要加锁，因为此时表dislock中已经有了一条ack_lock的记录，所以会报唯一键冲突，插入失败，也就是实例S2申请锁失败。

INSERT INTO dislock (`lock_type`, `owner_id`) VALUES ('act_lock', '8tfeb7u');

锁超时实现

需要有和超进程，定时检测dislock这张表，用当前时间减去update_time，如果超过最大持锁时间，就主动删除这条记录，释放锁。

重入锁实现

只需要在表dislock上再加个count字段，保存该锁被某个已持有该锁对象上锁的次数即可实现。

Mysql在解锁之后，没有主动通知的功能。S2及其他实例只能在获取锁失败后，休眠一会再主动轮询，看能否加锁。

5.2 Redis实现分布式锁

Redis是一种内存kv数据库，支持多种数据结构。string、list、hash、set、zset等等

说明：因为Redis的哨兵模式和cluster集群，采取的都是异步复制的方式，在当前使用的redis实例挂掉，后续补上的实例因为还没来得及复制，所以没有之前的锁资源，导致整个系统不可用。

5.2.1 Redis实现分布式锁的基础

加锁

NX 实现互斥语义

127.0.0.1:6379> set act_lock 111111 NX  // key:act_lock   uuid:111111   NX 表示只有当key不存在时，该命令执行成功，否则失败
OK
127.0.0.1:6379> set act_lock 222222 NX // 因为key:act_lock 已经存在,所以加锁失败
(nil)
127.0.0.1:6379> del act_lock   // 解锁act_lock
(integer) 1
127.0.0.1:6379> set act_lock 222222 NX // 因为key:act_lock 已经解除,所以加锁成功
OK
127.0.0.1:6379>

加锁和解锁都需要向Redis发送请求，redis返回加锁成功或者失败。

EX PX 实现锁超时。E表示expired，过期时间。EX的单位是：秒，PX的单位是：毫秒。

127.0.0.1:6379> set act_lock 333333 NX EX 10  // 加锁，并设置ack_lock 10秒后过期（解锁）
OK
127.0.0.1:6379> ttl act_lock  // ttl：time to life，查看act_lock剩余存活时间 5s
(integer) 5
127.0.0.1:6379> get act_lock  // 已删除
(nil)
127.0.0.1:6379>

解锁

注意：解锁，不能直接调用del act_lock，需要先get ack_lock获取持有锁的对象value，与自己比较，如果相等才调用del解锁。这三步不能被打断，也就是要原子操作，Redis提供LUA脚本实现原子操作。

1. get act_lock
2.if (val == uuid)
{
  3. // 解锁
  del act_lock ;
}

LUA 脚本实现解锁

--[[
  KEYS[1]   lock_name
  KEYS[2]   uuid
]]
local uuid = redis.call("get", KEYS[1])
if uuid == KEYS[2] then
  redis.call("del", KEYS[1])
end

Redlock实现

Redis一步复制，数据可能丢失，也就是说锁有可能丢失。

Redlock思路：

假设实例S1分别向5个不同的Redis进程发送加锁请求，其中R1、R2、R3这3个进程返回加锁成功，超过一半（5/2）的进程返回加锁成功，则加锁成功。假设一次网络交互的时间是40ms，三次成功的网络耗时是120ms，锁超时时间可以设置在5~10s的量级。

加锁：需要对每个进程执行加锁操作，超过半数以上则加锁成功；

解锁：需要对每个进程执行解锁操作，超过半数以上则解锁成功；

文章参考与<零声教育>的C/C++linux服务期高级架构。