分布式锁
在项目中，当共享资源出现竞争情况的时候，为了防止出现并发问题，我们一般会采用锁机制来控制。在单机环境下，可以使用synchronized或Lock来实现；但是在分布式系统中，因为竞争的线程可能不在同一个节点上（同一个jvm中），所以需要一个让所有进程都能访问到的锁来实现，比如mysql、redis、zookeeper
mysql作为分布式锁
通过增加删除数据来作为锁
在mysql中插入一条记录，表明获取锁。删除一条记录，表明释放锁。且在mysql表中设置一个unique key字段，当有一台机器获得锁后，其他机器无法获取。
-
如果一台机器获得锁，在释放锁之前进程挂了， 那么其他机器无法获取到锁。 可以引入锁有效时间的概念，超时后，删除记录，释放锁（必须做到可删除），同时产生告警。
-
万一获取锁的操作失败了，就直接做错误处理，也不太好。可以引入循环重试的方式来解决，控制重试次数。
通过给数据加排他锁来实现
适用场景: Mysql分布式锁一般适用于资源不存在数据库，如果数据库存在比如订单，那么可以直接对这条数据加行锁，不需要我们上面多的繁琐的步骤，比如一个订单，那么我们可以用select * from order_table where id = 'xxx' for update进行加行锁，那么其他的事务就不能对其进行修改。
优点:理解起来简单，不需要维护额外的第三方中间件(比如Redis,Zk)。
缺点:虽然容易理解但是实现起来较为繁琐，需要自己考虑锁超时，加事务等等。性能局限于数据库，一般对比缓存来说性能较低。对于高并发的场景并不是很适合。
使用redis作为分布式锁
1.加锁
最简单的方法是使用setnx命令。key是锁的唯一标识，按业务来决定命名，value为当前线程的线程ID。
比如想要给一种商品的秒杀活动加锁，可以给key命名为 “lock_sale_ID” 。而value设置成什么呢？我们可以姑且设置成1。加锁的伪代码如下：
setnx（key，1）当一个线程执行setnx返回1，说明key原本不存在，该线程成功得到了锁，当其他线程执行setnx返回0，说明key已经存在，该线程抢锁失败。
2.解锁
有加锁就得有解锁。当得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。释放锁的最简单方式是执行del指令，伪代码如下：
del（key）删除key，释放锁之后，其他线程就可以继续执行setnx命令来获得锁。
3.锁超时
锁超时是什么意思呢？如果一个得到锁的线程在执行任务的过程中挂掉，来不及显式地释放锁，这块资源将会永远被锁住，别的线程再也别想进来。
所以，setnx的key必须设置一个超时时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。expire（key， 30）
优点:对于Redis实现简单，性能对比ZK和Mysql较好。如果不需要特别复杂的要求，那么自己就可以利用setNx进行实现。
缺点:需要维护Redis集群，如果要实现RedLock那么需要维护更多的集群。
使用zookeeper作为分布式锁
进程需要访问共享数据时, 就在"/locks"节点下创建一个sequence类型的子节点, 称为thisPath. 当thisPath在所有子节点中最小时, 说明该进程获得了锁. 进程获得锁之后, 就可以访问共享资源了. 访问完成后, 需要将thisPath删除. 锁由新的最小的子节点获得.
进程如何知道thisPath是所有子节点中最小的呢? 可以在创建的时候, 通过getChildren方法获取子节点列表, 然后在列表中找到排名比thisPath前1位的节点, 称为waitPath, 然后在waitPath上注册监听, 当waitPath被删除后, 进程获得通知, 此时说明该进程获得了锁.
lock操作过程：
1、创建一个永久性节点，作锁的根目录
2、当要获取一个锁时，在锁目录下创建一个临时有序列的节点
3、检查锁目录的子节点是否有序列比它小，若有则监听比它小的上一个节点，当前锁处于等待状态
4、当等待时间超过Zookeeper session的连接时间（sessionTimeout）时，当前session过期，Zookeeper自动删除此session创建的临时节点，等待状态结束，获取锁失败
5、当监听器触发时，等待状态结束，获得锁
unlock操作过程：
将自己id对应的节点删除即可，对应的下一个排队的节点就可以收到Watcher事件，从而被唤醒得到锁后退出；
优点:ZK可以不需要关心锁超时时间，ZK获取锁会按照加锁的顺序，所以其是公平锁。zk的集群处理非常优秀，对于高可用利用ZK集群进行保证。
缺点:ZK需要额外维护，增加维护成本，性能和Mysql相差不大，依然比较差。并且需要开发人员了解ZK是什么。
