彻底弄清楚分布式锁

关于实现强一致性的手段，可以使用多种方式来进行实现，有分布式事务，有一致性算法，还有分布式锁等等，那么这篇文章我们就围绕分布式锁这个话题来进行展开，首先，我们会先探究它的原理，然后结合实际应用，对目前较为常见的分布式锁实现方式及注意事项进行详细的分析。

首先、大家可以先思考几个问题？

1. 什么时候需要加锁
2. 分布式锁有哪些特征
3. 如何用数据库实现分布式锁
4. 如何用Redis实现分布式锁（单机版+集群版）

什么时候需要加锁

我们先给出答案：

1. 有并发，多线程（这里指的是资源的使用者多，也就是在多任务环境下才可能需要锁的存在，多个任务想同时使用一个资源才有竞争的可能）
2. 有写操作（这里指的是资源的使用目的，如果是多个任务都是读请求的话，那反正这个资源就在那里，没有人改它，不同任务来读取的结果都是一样的，也就没有必要去控制谁先读谁后读）
3. 有竞争关系（这里指的是对资源的访问方式是互斥的，我们这个资源虽然是共享的，同但一时刻只能有一个任务占用它，不能同时共用，只能有一个任务占有它，这个时候我们需要给它上锁）

这么说可能有些同学觉得抽象，我举个栗子，可能不是很优雅但是比较形象：

就比如说你家里有一个厕所坑位，我们叫它为共享资源，你可以上，你家里人也可以上。好，如果现在家里只有你一个人，是不是你想什么时候上就什么时候上？想蹲多久都可以，想在里面睡觉也可以。这个时候就不存在竞争了，你不锁门也没人闯进来。然后，如果现在家里不止你一个人了，你的家里人也在了，但是呢，大家都不需要蹲坑，可能只是都想来看看有没有人在里面而已，看完就走了，那这个时候你还用不用进去然后锁门，然后再出来。最后，家里有多个人然后都憋不住了，是不是就得抢坑位了，先抢到的人，为了能够安静地顺利地。。。它就需要把门锁上了，免得其他人进来干扰。

这么说可以理解了吧，一多二写三互斥，如果还不理解就把上面的场景再脑补一下。

那如何上锁呢？

在单机环境下，也就是单个JVM环境下多线程对共享资源的并发更新处理，我们可以简单地使用JDK提供的ReentrantLock对共享资源进行加锁处理。

 

ReentrantLock lock = new ReentrantLock();try {    lock.lock();    //处理共享资源} finally {    lock.unlock();}

那如果是在微服务架构多实例的环境下，每一个服务都有多个节点，我们如果还是按照之前的方式来做，就会出现这样的情况：

 

这个时候再用ReentrantLock就没办法控制了，因为这时候这些任务是跨JVM的，不再是简单的单体应用了，需要协同多个节点信息，共同获取锁的竞争情况。

这时候就需要另一种形式的锁——分布式锁：

 

通常是把