随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题。
分布式锁主流的实现方案：
- 基于数据库实现分布式锁基于缓存（redis）基于Zookeeper
每一种分布式锁解决方案都有自己的优缺点：
- 性能：redis最高可靠性：zookeeper最高
这里，我们基于redis实现分布式锁
基于Redis实现Redis 分布式锁是基于 SETNX 来实现的。SETNX 是 “set if not exist” 的简称，当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。同时，key 还可以通过 expire命令 设置超时时间，通过 del命令删除key。
例：
setnx users 10 上锁
expire users 10 设置过期时间
但是如果上锁之后出现异常就无法设置过期时间了，所以我们可以采用下面的操作
set users 10 nx ex 12
nx代表上锁，ex代表过期时间为12秒，此时是让上锁与过期时间设置一同进行，此时将两个步骤变成了原子操作
查看过期时间：ttl users
手动释放锁：del users
UUID防止误删 问题：假如我们现在有三个操作要对同一个数据进行操作，设置过期时间10s，若a先抢到了：
- 上锁具体操作时，服务器卡顿（超过10s）锁自动释放
此时a的操作并未结束，然后b和c抢这把锁，假设b抢到了：
- 上锁具体操作（未完成）
此时a服务器反应过来，a继续进行操作，操作之后最终手动释放锁，但此时锁在b上，所以它会把b的锁释放，此时问题出现。释放锁的过程中将别人的锁释放。
解决方案- 利用UUID表示不同的操作 set lock uuid nx ex <过期时间>释放锁的时候，首先判断当前UUID和要释放锁的UUID是否一样
首先a先进行操作：
- 上锁具体操作释放锁（del）
- 比较uuid，发现一样删除操作的时候，正要删除但还没有删除，此时锁到了过期时间，自动释放，此时手动释放锁还未结束
然后b获取到锁：
- 上锁具体操作a的手动释放将b的锁释放
这个问题是由删除不是原子性操作造成的。
解决方案lua脚本：
优势：
将复杂的或者多步的redis操作，写成一个脚本，一次提交给redis执行，减少反复连接redis次数，提高性能LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作
为了确保分布式锁可用，我们至少要确保加锁的实现同时满足以下四个条件互斥性。在任意时刻，又有一个客户端能持有锁不会发生死锁，即一个客户端在持有锁的期间崩溃而没有主动解锁，又能保证后续其他客户端加锁加锁和解锁必须是同一个客户端枷锁和解锁必须具有原子性
