分布式锁介绍
在单机程序中，如果多条线程同时执行访问同一资源，这个资源被成为共享资源，如果它的状态会被每一条线程改变，那么每条线程就可能读取到一个已被其他线程改变的共享变量的状态从而导致获取共享变量的状态是失效的，在执行操作就会发生不可预知的结果。因此在多线程操作下我们需要对可变的共享资源进行加锁处理，这是程序中的锁。
分布式程序是相对于单机而言由多台服务器公共提供服务的程序，换言之程序部署在多台机器上，服务器间程序访问可变资源仍然需要有锁来控制，此时本地锁不会起到作用，需要利用其他辅助程序建立锁协助分布式程序加锁。在分布式程序中的锁就是分布式锁。
本文将介绍三种常用到的分布式锁实现，Zookeeper，Redis和Mysql实现。
Zookeeper
简单互斥锁
多个线程尝试在指定的目录下创建临时znode，只有一个线程会创建成功，占有锁，而其他线程设置watch监听这个临时znode。当占有锁的线程执行完成断开连接，临时znode消失，其他线程再一起尝试创建临时znode抢占锁，重复这个过程直到所有线程执行完成。无惊群效应的互斥锁
上面实现的简单互斥锁在程序量级很小的情况，实现简单好用。然后当程序量级增加，大量线程同时监听一个znode，每次释放锁时，所有线程都被唤醒去抢占锁，极大损耗网络资源和集群性能，这种现象称为惊群现象。
为了解决惊群现象，线程不在创建相同的临时znode，而是每个线程都创建一个顺序临时节点，znode序号最小线程的获得锁，其他线程只监听比它znode次序小的znode。这样分布式锁就会依据线程创建znode节点的次序依次被占有。自定义拓展的实现方式
在实际生产中会有许多根据需求而产生的特定加锁要求，例如对用户id加锁进行操作，同样可以利用上面介绍的两种方式实现，但这里存在一个问题就是如果用户数量很大将会产生大量的目录结构，每个用户一个目录结构，而有些用户可能操作一次之后就很久不再操作，这样就会导致Zookeeper集群内存的浪费。这时可以结合使用临时znode和持久znode，手动定义判断是否有线程占有锁的逻辑，删除不必要的znode节点。或者在zookeeper3以上定义了container节点类型，container节点如果其下面的最后一个孩子节点已经被删除，那么它也将被系统在未来某个时刻删除，使用container是要注意在其中创建子节点时可能存在KeeperException.NoNodeException无节点异常。
Redis
Redis的分布式锁在文章Redis分布式锁中已经详细介绍。
Mysql
利用UNIQUE KEY性质，多个线程获取锁时向Mysql数据库中插入一条记录，其中UNIQUE KEY都相同，如此就仅仅只能有一条线程可以成功插入，而其他线程会弹出异常表示唯一键已经存在，获取锁失败。
总结
目前随着互联网，尤其移动互联网的普及，越来越多的分布式系统被部署和提供服务。分布式锁是一个绕不开的话题。上面介绍了三中常见的实现方法，推荐使用Zookeeper和Redis相应的开源实现，更加稳定可靠，API丰富，避免重新造轮子。Mysql的实现仅仅是一种思路的扩充，实现起来笨拙，不推荐使用。
