应用场景
在业务传统场景下，单机版本的并发控制我们可以利用sychronized和retrantLock来完成，但是在集群环境下，不同的的JVM如何完成并发控制呢？这就需要利用分布式锁。
实现方式
1. 基于数据库的唯一约束实现
2. 基于缓存如Redis实现
3. 基于ZooKeeper实现
一 基于数据库的实现
实现思路：对lockMethod施加唯一约束
DROP TABLE IF EXISTS `c_table_lock_info`;
CREATE TABLE `c_table_lock_info` (
`id` int(11) NOT NULL AUTO_INCREMENT,,
`lockMethod` varchar(64) DEFAULT NULL COMMENT '锁定的方法名',
`remark` varchar(255) DEFAULT NULL COMMENT '备注信息',
`addTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`updTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_lockMethod` (`lockMethod`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='系统锁信息';
在之后每次遇到需要加锁的方法的时候，先执行以下SQL
INSERT INTO c_table_lock_info(lockMethod,remark) VALUES('加锁的方法名','方法备注');
如果多个请求都需要调用此方法，当其中某一个请求插入成功时，即可认为该请求获取了锁，完成相应的业务逻辑，在处理完之后，调用以下SQL
DELETE FROM c_table_lock_info WHERE lockMethod='加锁的方法名';
此时，锁被释放，可以再次被使用
但是存在一些缺点急需优化
1. 基于数据库实现，数据库的性能会直接影响锁的性能
2. 不具备可重入的性质，若在未释放锁之前，该请求再次调用此方法，导致无法插入数据，获取锁失败，需要加相应的认证信息，确认你还是你，但你还是你的时候，直接把锁给你
3. 锁没有相应的失效机制，在服务宕机之后，数据库中仍然存在该数据，当请求再次过来的时候，没有请求能获取到锁，需要加上失效时间，一段时间之后，锁自动失效
4. 没有阻塞特性，需要优化获取锁的代码逻辑，不断的循环重试去获取锁
二 基于缓存如Redis的实现
Redis是单线程的，也就是说存在很多客人来放松的时候，永远只有一个来处理客人要求的各种服务
实现思路：基于其实现的分布式锁思路就是利用原子命令来完成public String setex(final String key, final int seconds, final String value) {
在保存某一个key的时候并为其设置expirTime
return (String)(new JedisClusterCommand<String>(this.connectionHandler, this.maxAttempts) {
public String execute(Jedis connection) {
return connection.setex(key, seconds, value);
}
}).run(key);
}
为了保证在这种情况下的可重入性，仍然需要编写代码封装set
import redis.clients.jedis.Jedis;
import java.util.HashMap;
import java.util.Map;
/**
* @Description
* @Author taren
* @DATE 2019/8/22 16:29
*/
public class RedisLockTest01 {
private ThreadLocal<Map> lockers = new ThreadLocal<>();
private Jedis jedis;
public RedisLockTest01(Jedis jedis) {
this.jedis = jedis;
}
private boolean _lock(String key) {
return jedis.set(key, "", "nx", "ex", 5L) != null;
}
private void _unlock(String key) {
jedis.del(key);
}
private Map<String, Integer> currentLockers() {
Map<String, Integer> refs = lockers.get();
if (refs != null) {
return refs;
}
lockers.set(new HashMap<>());
return lockers.get();
}
public boolean lock(String key) {
Map refs = currentLockers();
Integer refCnt = (Integer) refs.get(key);
if (refCnt != null) {
refs.put(key, refCnt + 1);
return true;
}
if (!this._lock(key)) {
return false;
}
refs.put(key, 1);
return true;
}
public boolean unlock(String key) {
Map refs = currentLockers();
Integer refCnt = (Integer) refs.get(key);
if (refCnt == null) {
return false;
}
refCnt -= 1;
if (refCnt > 0) {
refs.put(key, refCnt);
} else {
refs.remove(key);
this._unlock(key);
}
return true;
}
}
当然setnx的加锁方式也是有缺陷的，完全可以编写Lua脚本来实现，用redis的connection对象去执行脚本
三 基于ZK的实现
实现思路：利用ZK的目录树特性结构，即同一目录下只能有唯一的文件名
1. 创建一个用来实现锁的目录lock
2. A线程获取锁，就在lock目录下创建顺序节点
3. 遍历lock目录，获取所有的子节点，A发现自己就是最小节点，获得锁
4. B线程遍历lock目录，发现自己不是最小节点，因为此时A才是最小节点，B对A设置监听
5. A使用完之后，删除节点，此时B发现自己是最小节点，B获得锁
