分布式锁的3种实现方式

有这3种方式：

• 基于数据库实现的分布式锁
• 基于Redis实现的分布式锁
• 基于Zookeeper实现的分布式锁

基于数据库的分布式锁

实现分布式锁最“简单”的方式就是直接创建一张锁表，通过操作表数据来实现加锁、解锁。

我们可以创建这样一张表

CREATE TABLE `myLock` (
 `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
 `method_name` varchar(100) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
 `value` varchar(1024) NOT NULL DEFAULT '锁信息',
 PRIMARY KEY (`id`),
 UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

注意：上面已经对method_name字段加了唯一索引

如果要锁住某方法，只要执行以下sql：

insert into myLock(method_name, value) values ('m1', '1');

因为我们对method_name做了唯一性约束，一个方法只能存在一条记录，如果有多条请求同时提交，最终也只会生效一条，所以操作成功的那个线程即获得了该方法的锁。

而当线程执行完这个方法后，需要释放锁，则执行以下sql：

delete from myLock where method_name ='m1';

这样就用数据库实现了一个最简单的加锁解锁过程，但是这把锁是不完善的。

让我们再回顾下分布式锁需要具备的几个条件：

• 互斥（必须）：同一时刻，分布式部署的应用中，同一个方法/资源只能被一台机器上的一个线程占用。

• 锁失效保护（必须）：出现客户端断电等异常情况，锁仍然能被其他客户端获取，防止死锁。

• 可重入（可选）：同一个线程在没有释放锁之前，如果想再次操作，可以直接获得锁。

• 阻塞/非阻塞（可选）：若没有获取到锁，返回获取失败

• 高可用、高性能（可选）：获取释放锁最好是原子操作，获取释放锁的性能要好

除了互斥，其他条件都存在一些问题：

1. 目前没有锁失效时间，如果解锁失败，就会导致锁记录永远留在数据库中，无法被其他线程获取，该方法就会永久不可用。

2. 该锁不可重入，因为它不认识请求方是不是当前占用锁的线程。

3. 该锁是非阻塞的，因为数据库插入操作失败会直接报错，线程只能再次请求获得锁。

4. 当前数据库是单点，一旦宕机，锁机制就会完全崩坏。

解决方案：

1. 针对锁失效问题，我们可以新增一个expire超时字段，在加锁时设置。

然后另起一个线程，负责轮询删除表中超时的数据。

2. 针对不可重入问题，我们可以再新增一个request_info字段，记录当前获取锁的线程的机器和线程信息，当相同的线程再次访问时，就可以识别放行了。

3. 针对非阻塞，还是和redis篇一样，写一个while死循环，失败了不断重拾，直到获取锁成功为止。

4. 针对单点问题，通用方案就是配置主从数据库。

总结

基于数据库实现分布式锁的优点：简单，易上手

缺点：性能问题