标签：事务 private exist char 传统 高可用性 put 文件名 .com
为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！
在分析分布式锁的三种实现方式之前，先了解一下分布式锁应该具备哪些条件：
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。
目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。
基于数据库实现分布式锁；
基于缓存（Redis等）实现分布式锁；
基于Zookeeper实现分布式锁；
尽管有这三种方案，但是不同的业务也要根据自己的情况进行选型，他们之间没有最好只有更适合！
基于数据库的实现方式的核心思想是：在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。
1.1 创建一个表：
DROP TABLE IF EXISTS `method_lock`;
CREATE TABLE `method_lock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT ‘主键‘,
`method_name` varchar(64) NOT NULL COMMENT ‘锁定的方法名‘,
`desc` varchar(255) NOT NULL COMMENT ‘备注信息‘,
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT=‘锁定中的方法‘;1.2 想要执行某个方法，就使用这个方法名向表中插入数据：
INSERT INTO method_lock (method_name, desc) VALUES (‘methodName‘, ‘测试的methodName‘);因为我们对method_name做了唯一性约束，这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。
1.3 成功插入则获取锁，执行完成后删除对应的行数据释放锁：
delete from method_lock where method_name =‘methodName‘;注意：这只是使用基于数据库的一种方法，使用数据库实现分布式锁还有很多其他的玩法！
上面这种简单的实现有以下几个问题：
当然，我们也可以有其他方式解决上面的问题。
数据库实现分布式锁的优点:直接借助数据库，容易理解。
数据库实现分布式锁的缺点:
选用Redis实现分布式锁原因：
（1）Redis有很高的性能；
（2）Redis命令对此支持较好，实现起来比较方便
缓存系统在实现的时候跟数据库的模式差不多，但是因为数据都是在缓存中，所以加锁和解锁都会比数据库快很多。
下面举例看看基于 Redis 的分布式锁实现。Redis 的分布式锁都是基于一个命令 -- SETNX，也就是 SET IF NOT EXIST，如果不存在就写入。从 Redis 2.6.12 版本开始，Redis 的 SET 命令直接直接设置 NX 和 EX 属性，NX 即附带了 SETNX 数据，key 存在就无法插入，EX 是过期属性，可以设置过期时间。这样一个命令就能原子的完成加锁和设置过期时间。
pom文件是这样。
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
<type>jar</type>
<scope>compile</scope>
</dependency>public class RedisManager {
public static JedisPool jedisPool;
private static final String LOCK_SUCCESS = "OK";
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";
private static final Long RELEASE_SUCCESS = 1L;
/**
*
* 过期时间设置
* EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。
* PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。
*
* 执行条件设置
* NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。
* XX ：只在键已经存在时，才对键进行设置操作。
*/
static {
//读取相关的配置
ResourceBundle resourceBundle = ResourceBundle.getBundle("redis");
int maxActive = Integer.parseInt(resourceBundle.getString("redis.pool.maxActive"));
int maxIdle = Integer.parseInt(resourceBundle.getString("redis.pool.maxIdle"));
int maxWait = Integer.parseInt(resourceBundle.getString("redis.pool.maxWait"));
String ip = resourceBundle.getString("redis.ip");
int port = Integer.parseInt(resourceBundle.getString("redis.port"));
JedisPoolConfig config = new JedisPoolConfig();
//设置最大连接数
config.setMaxTotal(maxActive);
//设置最大空闲数
config.setMaxIdle(maxIdle);
//设置超时时间
config.setMaxWaitMillis(maxWait);
//初始化连接池
jedisPool = new JedisPool(config, ip, port);
}
public static boolean tryLock(String key,String value,int expireSecond){
Jedis jedis = jedisPool.getResource();
if(jedis == null){
return false;
}
String result = jedis.set(key, value, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireSecond);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;
}
public static boolean releaseDistributedLock(String key,String value) {
Jedis jedis = jedisPool.getResource();
if(jedis == null){
return false;
}
String script = "if redis.call(‘get‘, KEYS[1]) == ARGV[1] then return redis.call(‘del‘, KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(key), Collections.singletonList(value));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
public static void main(String[] args){
Printer.println(tryLock("A","B",100));
Printer.println(releaseDistributedLock("A","B"));
}
}除此之外，Redis 的作者还实现了一个分布式锁算法，叫Redlock
以上实现方式同样存在几个问题：
当然，同样有方式可以解决。
但是，失效时间我设置多长时间为好？如何设置的失效时间太短，方法没等执行完，锁就自动释放了，那么就会产生并发问题。如果设置的时间太长，其他获取锁的线程就可能要平白的多等一段时间。这个问题使用数据库实现分布式锁同样存在
总结
可以使用缓存来代替数据库来实现分布式锁，这个可以提供更好的性能，同时，很多缓存服务都是集群部署的，可以避免单点问题。并且很多缓存服务都提供了可以用来实现分布式锁的方法，比如Tair的put方法，redis的setnx方法等。并且，这些缓存服务也都提供了对数据的过期自动删除的支持，可以直接设置超时时间来控制锁的释放。
使用缓存实现分布式锁的优点
ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下：
这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。
优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题。
缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式。
上面的三种实现方式，没有在所有场合都是完美的，所以，应根据不同的应用场景选择最适合的实现方式。
在分布式环境中，对资源进行上锁有时候是很重要的，比如抢购某一资源，这时候使用分布式锁就可以很好地控制资源。
当然，在具体使用中，还需要考虑很多因素，比如超时时间的选取，获取锁时间的选取对并发量都有很大的影响
参考：
http://www.hollischuang.com/archives/1716
https://blog.csdn.net/xlgen157387/article/details/79036337
https://toutiao.io/posts/8vnqlo/preview
标签：事务 private exist char 传统 高可用性 put 文件名 .com
原文地址：https://www.cnblogs.com/john8169/p/9189694.html
