实现分布式锁最“简单”的方式就是直接创建一张锁表，通过操作表数据来实现加锁、解锁。
实现方案
我们可以创建这样一张表
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='锁定中的方法';
如果要锁住某方法，只要执行以下sql：
insert into myLock(method_name, value) values ('m1', '1');
因为我们对method_name做了唯一性约束，一个方法只能存在一条记录，如果有多条请求同时提交，最终也只会生效一条，所以操作成功的那个线程即获得了该方法的锁。
而当线程执行完这个方法后，需要释放锁，则执行以下sql：
delete from myLock where method_name ='m1';
这样就用数据库实现了一个最简单的加锁解锁过程，但是这把锁是不完善的。
让我们再回顾下上回redis篇我们说到的分布式锁需要具备的几个条件：
互斥（必须）：同一时刻，分布式部署的应用中，同一个方法/资源只能被一台机器上的一个线程占用。
锁失效保护（必须）：出现客户端断电等异常情况，锁仍然能被其他客户端获取，防止死锁。
可重入（可选）：同一个线程在没有释放锁之前，如果想再次操作，可以直接获得锁。
阻塞/非阻塞（可选）：若没有获取到锁，返回获取失败
高可用、高性能（可选）：获取释放锁最好是原子操作，获取释放锁的性能要好
存在的问题
1. 目前没有锁失效时间，如果解锁失败，就会导致锁记录永远留在数据库中，无法被其他线程获取，该方法就会永久不可用。
2. 该锁不可重入，因为它不认识请求方是不是当前占用锁的线程。
3. 该锁是非阻塞的，因为数据库插入操作失败会直接报错，线程只能再次请求获得锁。
4. 当前数据库是单点，一旦宕机，锁机制就会完全崩坏。
解决方案
1. 针对锁失效问题，我们可以新增一个expire超时字段，在加锁时设置。
然后另起一个线程，负责轮询删除表中超时的数据。
2. 针对不可重入问题，我们可以再新增一个request_info字段，记录当前获取锁的线程的机器和线程信息，当相同的线程再次访问时，就可以识别放行了。
3. 针对非阻塞，还是和redis篇一样，写一个while死循环，失败了不断重拾，直到获取锁成功为止。
4. 针对单点问题，通用方案就是配置主从数据库。
总结
基于数据库实现分布式锁的优点：简单，易上手
缺点：性能问题
