厉害哥哥的博客

本节内容是关于使用分布式锁解决并发访问“超卖”问题的最终篇，在前面的章节中我们介绍了使用mysql的行锁、乐观锁、悲观锁解决并发访问导致的超卖问题，存在的问题是行锁、乐观锁、悲观锁不太灵活，需要和具体的业务耦合到一起，不利于使用，本节内容我们通过mysql的唯一索引特性，数据不能重复插入，达到独占排它的基本要求，实现通用的分布式锁功能。

本节内容使用zookeeper实现分布式锁，完成并发访问“超卖”问题的解决。相对于redis分布式锁，zookeeper能够保证足够的安全性。关于zookeeper的安装内容这里不做介绍，开始本节内容之前先自行安装好zookeeper中间键服务。这里我们利用创建zookeeper路径节点的唯一性实现分布式锁。并同时演示如何使用Curator工具包，完成分布式锁。

在上一节内容中，我们已经实现了使用redis分布式锁解决商品“超卖”的问题，本节内容是对redis分布式锁的优化。在上一节的redis分布式锁中，我们的锁有俩个可以优化的问题。第一，锁需要实现可重入，同一个线程不用重复去获取锁；第二，锁没有续期功能，导致业务没有执行完成就已经释放了锁，存在一定的并发访问问题。本案例中通过使用redis的hash数据结构实现可重入锁，使用Timer实现锁的续期功能，完成redis分布式锁的优化。最后，我们通过集成第三方redisson工具包，完成分布式锁以上俩点的优化内容。R

在上一节内容中我们介绍了如何使用mysql数据库的传统锁（行锁、乐观锁、悲观锁）来解决并发访问导致的“超卖问题”。虽然mysql的传统锁能够很好的解决并发访问的问题，但是从性能上来讲，mysql的表现似乎并不那么优秀，而且会受制于单点故障。本节内容我们介绍一种性能更加优良的解决方案，使用内存数据库redis实现分布式锁从而控制并发访问导致的“超卖”问题。关于redis环境的搭建这里不做介绍，可查看作者往期博客内容。

在上一节内容中，我们详细介绍了超卖问题产生的原因，以及在单应用的项目中，如何解决超卖的问题——通过jvm本地锁控制并发访问从而解决“超卖问题”。同时我们也提出本地锁只能解决单应用服务的超卖问题，本节内容我们话接上篇，使用传统锁的方式解决在多应用服务访问中的并发问题。主要是通过mysql的乐观锁和悲观锁解决解决并发问题。

前言正文结语

前言在上一小节我们详细讲解了使用MYSQL数据库实现分布式锁的技术方案及实现细节案例，本节我们使用zookeeper方式实现分布式锁，原理同上，依然是使用共享资源获取锁，从而实现分布式锁。zookeeper具备高可用、可重入、阻塞锁特性、可解决失效死锁问题。正文docker-compose安装高可用的zookeeper实例集群使用vi工具创建一个zookeeper集群启动脚本zookeeper-cluster.ymlversion: '3.1'services: zoo1:

前言随着分布式、微服务应用的流行，同时也伴随着一些新问题的产生以及解决这些问题的技术方案，如服务注册与发现、负载均衡、网关、布式锁、分布式事务等等。本节我们主要讲一下分布式锁的应用。实战案例依然使用我们多次提到的ATP应用测试平台实现。关于分布式锁的章节，我们会分为三小节来讲解，分别是基于MYSQL数据库方式实现分布式锁、基于zookeeper实现分布式锁、基于缓存redis实现分布式锁这三大分布式技术解决方案。并为每一小节提供一个实战案例，本小节我们主要使用mysql的乐观锁实现分布式锁方案。正文