在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式 锁的实现目前有以下方案。
一 基于数据库实现分布式锁
二 基于缓存（redis，memcache）实现分布式锁
三 基于Zookeeper实现分布式
首先在分析这些锁的具体实现之前我们应该考虑一下我们想要的锁到底是什么样的呢？
1，加锁时，加锁的内容只允许预期的线程进入。
2，加锁和释放锁的性能很好
一,基于数据库实现分布式锁
要实现分布式锁，最简单的方式可能就是直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。创建这样一张数据库表：在这张表中我们可以把方法名和特定参为数据库表的主键，新增成功则表示获得锁，失败则表示获取锁失败。当方法执行结束后则删除此条记录。
上面这种简单的实现有以下几个问题
1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
当然我们也可以有其他方式解决上面的问题。
数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
非阻塞的？搞一个while循环不断轮询，直到insert成功再返回成功。
非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
数据库实现分布式锁的优点
直接借助数据库，容易理解，系统结果简单，借助已有的数据库不需要引入其他服务。
数据库实现分布式锁的缺点
会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。
操作数据库需要一定的开销，性能问题需要考虑
二，基于Zookeeper实现分布式锁
大致思想即为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。
来看下Zookeeper能不能解决前面提到的问题。
锁无法释放？使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
非阻塞锁？使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
不可重入？使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
单点问题？使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
使用Zookeeper实现分布式锁的优点
有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。实现起来较为简单。
基于缓存实现分布式锁
相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的，可以解决单点问题。
目前有很多成熟的缓存产品，其中我们接下来讲着重讲用radis实现分布式锁的过程。
思路：当进入方法时，我们将方法名和限定参数作为key存入radis，执行结束后，删除key，由于存在程序中断，导致radis连接断掉，无法释放锁的问题我们在值的时候存一个过期时间，当key已存在我们拿当前时间跟过期时间做比较。具体用到的命令 setnx del get 考虑到加锁这个过程是一个公共过程我们打算抽出一个切面。使用声明注解拦截。
具体步骤如下
1，声明注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RedLock {
String value()default "";
}
2,释放锁和获取锁的公共方法
说明;radis以用setnx命令实现设置值，如果键已经存在则设置失败返回0，如果设置成功则返回1.
获取锁getlock
boolean success =false;
// 加锁结果
long lockResult =0L;
lockResult = JedisClientUtils.setnx(lockkey, String.valueOf("过期时间"));
// 等于1成功，则成功获取一个锁
if (lockResult ==1) {
return true；
}
else{
// 失败，说明锁仍然被其他线程占用，判断是否超时
String lockValue = JedisClientUtils.getV(lockkey);
// 检查其是否已经超时
if(StringUtils.isNotBlank(lockValue)){
long oldValue = Long.parseLong(lockValue);
// 如果超时，获取锁
if (oldValue < System.currentTimeMillis()) {
String getValue = JedisClientUtils.getSet(lockkey, String.valueOf(value));
// 获取锁成功
if (Long.parseLong(getValue) == oldValue) {
return true;
}else{
return false；
}
释放锁 releaselock
JedisClientUtils.delV(lockkey)
3 做公共切面
//拦截注解 锁的
@Around("@annotation(redLock)")
public Object aroud(ProceedingJoinPoint point,RedLock redLock) {
//获取方法名称
String methodName = point.getSignature().getName();
//注解属性
String value = redLock.value();
StringBuilder appendKey =new StringBuilder("系统名称");
//拼接key 加锁可以更细微化比如订单号
appendKey.append(value.toUpperCase());
appendKey.append("_").append(methodName);
boolean lockResult =getLocker(lockKey,“”过期时间“”);
if (lockResult){
try {
return point.proceed();
}
catch (Throwable throwable) {
return false;
}finally {
JedisClientUtils.delV(lockKey);
}
else{
return false
}
}
