那么，这样的话，我们就可以认为获得了排它锁的这个线程是拥有了分布式锁，然后就可以执行我们想要做的业务逻辑，当逻辑完成之后，再调用上述释放锁的语句即可。
基于Redis实现
基于Redis实现的锁机制，主要是依赖redis自身的原子操作，例如：
SET user_key user_value NX PX 100
redis从2.6.12版本开始，SET命令才支持这些参数：
NX：只在在键不存在时，才对键进行设置操作，SET key value NX 效果等同于 SETNX key value
PX millisecond：设置键的过期时间为millisecond毫秒，当超过这个时间后，设置的键会自动失效
上述代码示例是指，当redis中不存在user_key这个键的时候，才会去设置一个user_key键，并且给这个键的值设置为 user_value，且这个键的存活时间为100ms
为什么这个命令可以帮我们实现锁机制呢？
因为这个命令是只有在某个key不存在的时候，才会执行成功。那么当多个进程同时并发的去设置同一个key的时候，就永远只会有一个进程成功。
当某个进程设置成功之后，就可以去执行业务逻辑了，等业务逻辑执行完毕之后，再去进行解锁。
解锁很简单，只需要删除这个key就可以了，不过删除之前需要判断，这个key对应的value是当初自己设置的那个。
另外，针对redis集群模式的分布式锁，可以采用redis的Redlock机制。
基于ZooKeeper实现
其实基于ZooKeeper，就是使用它的临时有序节点来实现的分布式锁。
原理就是：当某客户端要进行逻辑的加锁时，就在zookeeper上的某个指定节点的目录下，去生成一个唯一的临时有序节点， 然后判断自己是否是这些有序节点中序号最小的一个，如果是，则算是获取了锁。如果不是，则说明没有获取到锁，那么就需要在序列中找到比自己小的那个节点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是，则获取锁，如果不是，则重复上述步骤。
当释放锁的时候，只需将这个临时节点删除即可。
如图，locker是一个持久节点，node_1/node_2/…/node_n 就是上面说的临时节点，由客户端client去创建的。
client_1/client_2/…/clien_n 都是想去获取锁的客户端。以client_1为例，它想去获取分布式锁，则需要跑到locker下面去创建临时节点（假如是node_1）创建完毕后，看一下自己的节点序号是否是locker下面最小的，如果是，则获取了锁。如果不是，则去找到比自己小的那个节点（假如是node_2），找到后，就监听node_2，直到node_2被删除，那么就开始再次判断自己的node_1是不是序列中最小的，如果是，则获取锁，如果还不是，则继续找一下一个节点。
以上，就讲完了为什么我们需要分布式锁这个技术，以及分布式锁中常见的三种机制。