面试连环炮之分布式锁
面试连环炮系列专栏，暂不想换工作的同学可补充知识盲点查缺补漏，准备换工作的同学可针对性突击训练，不打无准备之战。面试战场所向披靡，成为offer收割机，找到心仪的工作。
楼主努力更新，争取每日多更。有想关注的方向可留言，楼主针对性更新。已更新的内容也会不断更新完善增加更多的"炮弹"，祝大家面试时可以吊打面试官。
目录
1、为什么使用分布式锁？
2、分布式锁的设计注意事项
3、分布式锁有哪些实现方式
4、基于Redis的实现方式
5、Redssion锁分类
6、zk实现分布式锁
7、zk使用场景
8、对比
9、zk生产环境部署情况
1、为什么使用分布式锁？
为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！
目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。
2、分布式锁的设计注意事项
互斥：在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点。
不能死锁：在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令,导致其它线程都无法获得锁，造成死锁。
所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况。
性能：对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。
所以在锁的设计时，需要考虑两点。
锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的ID,而不是任取名称。这样这个锁只对当前商品有效,锁的颗粒度小。
锁的范围尽量要小。比如只要锁2行代码就可以解决问题的，那就不要去锁10行代码了。
3、分布式锁有哪些实现方式
一般分布式锁有三种实现方式：基于数据库、基于缓存（redis）、基于Zookeeper。
基于数据库的分布式锁不太常用，所以不做深入讨论。
4、基于Redis的实现方式
1、选用Redis实现分布式锁原因：
（1）Redis有很高的性能；
（2）Redis命令对此支持较好，实现起来比较方便
redis有两种实现方式
1、基于SETNX命令实现
推荐使用NX的方式
SET resource_name my_random_value NX PX 30000
NX：表示只有 key 不存在的时候才会设置成功。（如果此时 redis 中存在这个 key，那么设置失败，返回 nil）
PX 30000：意思是 30s 后锁自动释放。别人创建的时候如果发现已经有了就不能加锁了2、使用Redisson
Redisson中加锁/释放锁操作都是用lua脚本完成的，封装的非常完善，开箱即用。极大的简化了分布式锁的实现。
Redisson还实现了多种锁策略，可根据业务场景自行选择。
5、Redssion锁分类
1. 可重入锁（Reentrant Lock）
Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。
Redisson同时还为分布式锁提供了异步执行方法。
2. 公平锁（Fair Lock）
Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。
3. 联锁（MultiLock）
Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。
4. 红锁（RedLock）
Redisson的RedissonRedLock对象实现了Redlock介绍的加锁算法。该对象也可以用来将多个RLock
对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。
5. 读写锁（ReadWriteLock）
Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。同时还支持自动过期解锁。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。
6. 信号量（Semaphore）
Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法
7. 可过期性信号量（PermitExpirableSemaphore）
Redisson的可过期性信号量（PermitExpirableSemaphore）实在RSemaphore对象的基础上，为每个信号增加了一个过期时间。每个信号可以通过独立的ID来辨识，释放时只能通过提交这个ID才能释放。
8. 闭锁（CountDownLatch）
Redisson的分布式闭锁（CountDownLatch）Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。
6、zk实现分布式锁
curator基于zk实现分布式锁，可实现共享不可重入锁，共享可重入锁，信号量等。
7、zk使用场景
分布式协调
这个其实是 zookeeper 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zookeeper 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zookeeper 上对某个节点的值注册个监听器，一旦 B 系统处理完了就修改 zookeeper 那个节点的值，A 系统立马就可以收到通知，完美解决。
分布式锁
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就可以使用 zookeeper 分布式锁，一个机器接收到了请求之后先获取 zookeeper 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。
元数据/配置信息管理
zookeeper 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zookeeper 来做一些元数据、配置信息的管理，包括 dubbo 注册中心不也支持 zookeeper 么？
HA高可用性
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zookeeper 来开发 HA 高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过 zookeeper 感知到切换到备用进程。
8、对比
实现难度上：Zookeeper >= redis
服务端性能：redis > Zookeeper
客户端性能：Zookeeper > redis
可靠性：Zookeeper > redis
选型的时候，该如何做呢？这要看你的基础设施。如果你的应用用到了zk，而且集群性能很强劲，优选zk。如果你只有redis，不想为了个分布式锁，引入臃肿的zk，那就用redis。
9、zk生产环境部署情况
暂略
不管你多牛，一定要提前准备，千万不要裸面。另外面试准备也尽量不要死记硬背，要结合自己项目的情况有自己的见解。不管是面试中级、高级还是架构岗位都最好准备一些新技术架构的思考，比如云原生、Service Mesh、中台、DevOps等等。
关注公众号小猿架构，发送 yys 免费获取 《云原生技术与架构实践》。
