赞看，养成习惯，微信搜索【三太子rzdbg】关注这个网络不雅偷窃的工具人。
本文http://www.Sina.com/https://github.com/Java family已收录，有一线大厂面试的完整考点、资料及我系列文章。
我觉得前言锁门不需要我多说，大家知道发生了什么吧？
在多线程环境中，由于上下文切换可能会导致数据不一致、数据受到污染，需要确保数据安全，因此我们考虑进行锁定。
锁定机制是在一个线程访问该类中的某个数据时提供保护，使其他线程无法访问。 在此线程读完之前，其他线程不可用。
我记得我说过，如果Redis是分布式的，就需要同时锁定冲突的数据。 丈夫们非常费解。 Redis是单线程的吗？ 为什么要锁门？
丈夫们好像还年轻呢。 你说的不需要封锁的情况是这样的：
当单个服务访问Redis时，确实不需要考虑线程安全，因为Redis本身是单线程的。 但是，现在也有独立的公司吗？ 一定是分散集群吧。
丈夫们看到这样的场景不是有问题吗？
你们不是经常说秒杀吗？ 拿到库存进行判断。 那个妻子告诉你分散情况会成为问题。
我们为了减少数据库的压力，把库存预热到了KV。 现在KV的库存是1。
服务a去Redis查库存发现是1。 那说明我可以抢走这个商品。 那样的话，我打算减少1，但是还没有减少。 同时服务b和去拿发现都是1，那我也抢了啊。 那我也减少。 C也一样。 所有服务结束后，你会发现是怎么变成-2的，超卖的，就这样结束了。 丈夫们注意到问题了吗？ 那需要分散锁定的介入。 分为三章分别介绍分布式锁定的三种实现方法(Zookeeper、Redis、MySQL )，阐述他们的优缺点，以及一般大型制造商的实践场景。
正文里什么都没带就进来了看起来很吵的面试官。 你看，这不是夫人吗？ 我想叫他的时候，他一脸认真，死鬼假装认真。 一定会放水的吧。
B站搜索：三太子rzdbg咳嗽，我们什么也别说，开始今天的面试吧。
正常线程进程的同步机制是什么？
互斥：一种互斥机制，允许一个线程同时只处理共享资源同步、锁定等。 阈值)同时访问多个任务(使多线程串行访问资源事件通知)并通过事件通知有序地访问共享资源信号量，从而同时限制数量。 例如，你知道过发令枪CDL、Semaphore等分布式锁吗？
分布式锁定的实现主要以Zookeeper (以下简称zk )、Redis、MySQL三种为主。
先谈谈zk吧。 能告诉我他常见的使用场景吗？
他的主要应用场景如下。
注册和订阅服务(共享节点)分布式通知) znode侦听)服务命名) znode特性)订阅、发布数据) watcher )分布式锁定) zk是什么？
他是数据库、文件存储系统，有监听通知机制(观察员模式)
保存文件系统。 他保存了什么？
节点
zk的节点类型有四个类别
持久化节点(仍有zk断开连接节点) ) ) )。
持久化序列号目录节点
临时目录节点(客户端断开连接时节点将被删除)。
临时目录编号目录节点
所有节点名称都是唯一的。
节点是如何创建的？
我特别是这样问的吗？ 但是面试只看分散锁。 必须仔细考虑。
我以前用自己的服务器构建了zk的集群，正好和大家一起想起了一波。
要在其中创建创建/测试标签//永久节点的临时节点是什么？
已成功创建创建- e/test laogong//临时节点。 切断这次的链接后，这个节点会自然消失。 这是我的zk管理工具，目录可能很清楚。
如何创建顺序节点？
创建- s/test//创建顺序节点临时顺序节点是什么？
我想聪明的丈夫都会回答的
创建create-e-s/test//虚拟顺序节点后，重新连接时发现刚才创建的所有虚拟顺序节点都不见了。
开头的示威这么多啊。 我想给大家看的zk的大致操作流程和数据结构。 虽然中途不说相关的构建和其他技能，但是让我们重点谈谈在分散锁定上实现他吧。
zk基于节点实现各种分布式锁定。
就开头的场景而言，zk该如何确保分布式情况下的线程安全呢？ 他是怎么控制的呢？
为了模拟和竞争这种情况，我写了伪代码。 大家先
看看我定义了一个库存inventory值为1，还用到了一个CountDownLatch发令枪，等10个线程都就绪了一起去扣减库存。
是不是就像10台机器一起去拿到库存，然后扣减库存了？
所有机器一起去拿，发现都是1，那大家都认为是自己抢到了，都做了减一的操作，但是等所有人都执行完，再去set值的时候，发现其实已经超卖了，我打印出来给大家看看。
是吧，这还不是超卖一个两个的问题，超卖7个都有，代码里面明明判断了库存大于0才去减的，怎么回事开头我说明了。
那怎么解决这个问题？
sync，lock也只能保证你当前机器线程安全，这样分布式访问还是有问题。
上面跟大家提到的zk的节点就可以解决这个问题。
zk节点有个唯一的特性，就是我们创建过这个节点了，你再创建zk是会报错的，那我们就利用一下他的唯一性去实现一下。
怎么实现呢？
上面不是10个线程嘛？
我们全部去创建，创建成功的第一个返回true他就可以继续下面的扣减库存操作，后续的节点访问就会全部报错，扣减失败，我们把它们丢一个队列去排队。
那怎么释放锁呢？
删除节点咯，删了再通知其他的人过来加锁，依次类推。
我们实现一下，zk加锁的场景。
是不是，只有第一个线程能扣减成功，其他的都失败了。
但是你发现问题没有，你加了锁了，你得释放啊，你不释放后面的报错了就不重试了。
那简单，删除锁就释放掉了，Lock在finally里面unLock，现在我们在finally删除节点。
加锁我们知道创建节点就够了，但是你得实现一个阻塞的效果呀，那咋搞？
死循环，递归不断去尝试，直到成功，一个伪装的阻塞效果。
怎么知道前面的老哥删除节点了嗯？
监听节点的删除事件
但是你发现你这样做的问题没？
是的，会出现死锁。
第一个仔加锁成功了，在执行代码的时候，机器宕机了，那节点是不是就不能删除了？
你要故作沉思，自问自答，时而看看远方，时而看看面试官，假装自己什么都不知道。
哦我想起来了，创建临时节点就好了，客户端连接一断开，别的就可以监听到节点的变化了。
嗯还不错，那你发现还有别的问题没？
好像这种监听机制也不好。
怎么个不好呢？
你们可以看到，监听，是所有服务都去监听一个节点的，节点的释放也会通知所有的服务器，如果是900个服务器呢？
这对服务器是很大的一个挑战，一个释放的消息，就好像一个牧羊犬进入了羊群，大家都四散而开，随时可能干掉机器，会占用服务资源，网络带宽等等。
这就是羊群效应。
那怎么解决这个问题？
继续故作沉思，啊啊啊，好难，我的脑袋。。。。
你TM别装了好不好？
好的，临时顺序节点，可以顺利解决这个问题。
怎么实现老公你先别往下看，先自己想想。
之前说了全部监听一个节点问题很大，那我们就监听我们的前一个节点，因为是顺序的，很容易找到自己的前后。
和之前监听一个永久节点的区别就在于，这里每个节点只监听了自己的前一个节点，释放当然也是一个个释放下去，就不会出现羊群效应了。
以上所有代码我都会开源到我的https://github.com/AobingJava/Thanos其实上面的还有瑕疵，大家可以去拉下来改一下提交pr，我会看合适的会通过的。
你说了这么多，挺不错的，你能说说ZK在分布式锁中实践的一些缺点么？
Zk性能上可能并没有缓存服务那么高。
因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。
ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。（这里涉及zk集群的知识，我就不展开了，以后zk章节跟老公们细聊）
还有么？
使用Zookeeper也有可能带来并发问题，只是并不常见而已。
由于网络抖动，客户端可ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。
就可能产生并发问题了，这个问题不常见是因为zk有重试机制，一旦zk集群检测不到客户端的心跳，就会重试，Curator客户端支持多种重试策略。
多次重试之后还不行的话才会删除临时节点。
Tip：所以，选择一个合适的重试策略也比较重要，要在锁的粒度和并发之间找一个平衡。
有更好的实现么？
基于Redis的分布式锁
能跟我聊聊么？
我看看了手上的表，老公，今天天色不早了，你全问完了，我怎么多水几篇文章呢？
行确实很晚了，那你回家去把家务干了吧？
我？？？？
= 总结zk通过临时节点，解决掉了死锁的问题，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉，其他客户端自动获取锁。
zk通过节点排队监听的机制，也实现了阻塞的原理，其实就是个递归在那无限等待最小节点释放的过程。
我上面没实现锁的可重入，但是也很好实现，可以带上线程信息就可以了，或者机器信息这样的唯一标识，获取的时候判断一下。
zk的集群也是高可用的，只要半数以上的或者，就可以对外提供服务了。
这周会写完Redis和数据库的分布式锁的，老公们等好。
我是rzdbg，一个在互联网苟且偷生的工具人。
最好的关系是互相成就，老公们的「三连」就是丙丙创作的最大动力，我们下期见！
注：如果本篇博客有任何错误和建议，欢迎老公们留言，老公你快说句话啊！
文章持续更新，可以微信搜索「 三太子rzdbg 」第一时间阅读，回复【资料】【面试】【简历】有我准备的一线大厂面试资料和简历模板，本文 GitHub https://github.com/JavaFamily 已经收录，有大厂面试完整考点，欢迎Star。
你知道的越多，你不知道的越多