Java实战分布式锁实战之重现高并发场景一

Posted 2021-05-01 程序员实战基地

程序员实战基地

（关注一起成长）

关注

在之前的文章中debug总体介绍了“SpringBoot实战实现分布式锁” 总体涉及的内容（可点击查看文章：）。从本篇文章开始，debug将开始介绍其中涉及到的相关知识要点，感兴趣的小伙伴可以关注关注学习学习！！

工欲善其事，必先利其器，介绍分布式锁使用的前因后果之前，得先想办法说清楚为啥需要分布式锁以及如何才需要将分布式锁搬上用场！！故而此文将介绍一下分布式锁出现的背景以及如何才能将分布式锁搬上用场（即如何重新多线程高并发的场景）。

“同一时刻多个线程高并发下访问共享资源”的场景在当前互联网产品或者项目下并不少见，这一场景随之带来的问题便显而易见：共享资源在并发访问的前后出现了数据不一致或者并非预期出现的结果的现象！！

简而言之，这种现象其实就是大伙熟悉的 “高并发多线程访问共享资源时需要加同步代码块”的口头语（甚至可以说是面试时常见的对白了！）

 

单体应用时代加“同步锁”常见的方式是利用jdk天然提供的类/组件：ReentrantLock或者Synchronized，但在分布式系统架构下项目一般以微服务的方式开发、独立部署甚至集群部署，当不同的服务或者集群环境同一服务不同实例发生对共享资源的高并发访问时，ReentrantLock或者Synchronized 的方式将很难解决 “高并发导致数据不一致或者并发预期出现的结果”的问题！！

 

于是乎，“分布式锁”便出现了，“分布式锁”其实只是解决方案，并非专有组件或者类，实现这一解决方案仍旧需要额外的组件或者中间件来辅助，甚至某些情况下，需要借助数据库级别的方式来实现。总体来说，目前较为流行的解决方式还是有很多种，在我的视频课程或者文章中，我将介绍一下几种方式来实战实现 “分布式锁”

（1）数据库级别锁-乐观锁和悲观锁

（2）基于Redis的原子操作实现分布式锁

（3）基于Zookeeper实战实现分布式锁

（4）基于Redisson实战实现分布式锁

 

既然我们知道分布式锁出现的背景以及其相应的实战实现方式，那我们回到本篇文章的核心内容：重现多线程高并发访问共享资源的场景

 

下面我们以“商城系统/秒杀系统抢单”场景为例，借助Jmeter测试工具，基于SpringBoot微服务项目重现高并发多线程访问共享资源的场景！即：重现1秒内100线程、1000线程、10000线程等充当抢单请求对一商品进行抢单！！！

 

这一场景其实很像“抢微信红包”、“某一商城如小米商城饥饿营销时抢手机”等业务场景。下面我们大概模拟重现其中的核心逻辑-即抢单的过程：建库-spring_boot_distribute，建一商品信息表语句如下（mysql5.6版本）：

点击查看大图

 

并在其中录入一个商品的信息（主要是库存 stock 的设置）！

点击查看大图

接着采用IDEA的SpringBoot Initializr组件构建多模块的SpringBoot微服务项目，并开发一Controller跟一Service，采用Mybatis逆向工程生成上面那张数据库表对应的entity、mapper、mapper.xml，相关代码以及截图如下：

点击查看大图

DataLockController代码如下：

点击查看大图

ProductLockDto 代码如下：

点击查看大图

Mybatis逆向工程生成的那三个组件就不贴了，在这里贴一下 DataLockService调用的ProductLockMapper更新库存的方法以及动态sql的写法，即：

ProductLockMapper类的方法：
int updateStock(ProductLock lock);

ProductLockMapper.xml的动态sql：

点击查看大图

至此简单的抢单系统/商城秒杀系统的抢单场景就大致模拟好了，然后我们跑起来，接下来我们得采用某种工具来复现此种高并发的场景，那就是Jmeter压力测试工具！欲知详情如何，请听下回分解！！

如需完整源码请添加

QQ：1974544863

或微信：SteadyJack

 

debug有话说

希望大家拿到视频教程以及资料后，可以静下心来学习研究，在学习本课程过程中，加上自己的撸码实战，我相信大家将能接触到更多的微服务、分布式系统的相关技术要点以及其中的分布式锁的实际实战业务场景，更进一步的完善诸位小伙伴的知识体系！！

1

END

1

点赞的朋友

写代码从此无bug