分布式锁

可以使用select ... for update 来实现分布式锁。我们自己的项目，分布式定时任务 ，
就使用类似的实现方案
MySQL设置innodb_lock_wait_timeout超时时间

乐观锁，顾名思义，就是很乐观，每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。它是基于CAS思想实现的

if（jedis.setnx(key,lock_value) == 1）{ //setnx加锁
    //走在这里redis断了lock就永远锁住了
    expire（key，100）; //设置过期时间
    try {
        do something  //业务处理
    }catch(){
    }
  finally {
       jedis.del(key); //释放锁
    }
}

这段代码是可以加锁成功，但是你有没有发现问题，加锁操作和设置超时时间是分开的 。假设在执行完setnx加锁后，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就长生不老 了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现 ！

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}

缺点

SET key value [EX seconds] [PX milliseconds] [NX|XX]

if（jedis.set(key, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       jedis.del(key); //释放锁
    }
}

这个方案可能存在这样的问题：

if（jedis.set(key, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key))) {
          //这里如果代码刚好超时就别的线程刚好获取锁就把别的线程给删了
          jedis.del(key); //释放锁
        }
    }
}

在这里，判断当前线程加的锁和释放锁不是一个原子操作 。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端 ，会解除他人加的锁。

一般可以用lua脚本包装一下

缺点：锁过期释放了，业务还没执行完的问题 。

对于可能存在锁过期释放，业务没执行完 的问题。我们可以稍微把锁过期时间设置长一些，大于正常业务处理时间就好啦。如果你觉得不是很稳，还可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放

redisson解决问题的思路

Redisson + RedLock

持久节点 ：默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。

持久节点顺序节点 ：所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号，持久节点顺序节点就是有顺序的持久节点。

临时节点 ：和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

临时顺序节点 ：有顺序的临时节点。

zk获取锁过程

优点：

简单，使用方便，不需要引入Redis、zookeeper等中间件。
缺点：

不适合高并发的场景
db操作性能较差；

优点：

性能好，适合高并发场景
较轻量级
有较好的框架支持，如Redisson
缺点：
aof rdb的存储方式可能会丢数据
过期时间不好控制
需要考虑锁被别的线程误删场景

缺点：

性能不如redis实现的分布式锁
比较重的分布式锁。
优点：

有较好的性能和可靠性
有封装较好的框架，如Curator

从性能角度（从高到低）Redis > Zookeeper >= 数据库；
从理解的难易程度角度（从低到高）数据库 > Redis > Zookeeper；
从实现的复杂性角度（从低到高）Zookeeper > Redis > 数据库；
从可靠性角度（从高到低）Zookeeper > Redis > 数据库。