我彻底看愣了，现在才知道MySQL还能实现分布式锁？

最新推荐文章于 2024-08-19 18:38:36 发布

java 分享官

最新推荐文章于 2024-08-19 18:38:36 发布

阅读量162

点赞数

文章标签： java mysql 分布式

本文链接：https://blog.csdn.net/aa119101/article/details/124454443

版权

本文探讨了在微服务架构中单体应用锁的局限性，并介绍了分布式锁的概念和设计思路。通过示例展示了如何基于数据库的悲观锁实现分布式锁，通过控制事务和`SELECT ... FOR UPDATE`来确保锁的效果。同时指出了数据库锁在高并发时可能对数据库造成压力，并建议与业务数据库分开。最后提到Redis和Zookeeper也是常用的分布式锁实现方式，但将在后续文章中分享。

摘要由CSDN通过智能技术生成

前言

之前的文章中通过电商场景中秒杀的例子和大家分享了单体架构中锁的使用方式，但是现在很多应用系统都是相当庞大的，很多应用系统都是微服务的架构体系，那么在这种跨jvm的场景下，我们又该如何去解决并发。

单体应用锁的局限性

在进入实战之前简单和大家粗略聊一下互联网系统中的架构演进。

在互联网系统发展之初，消耗资源比较小，用户量也比较小，我们只部署一个tomcat应用就可以满足需求。一个tomcat我们可以看做是一个jvm的进程，当大量的请求并发到达系统时，所有的请求都落在这唯一的一个tomcat上，如果某些请求方法是需要加锁的，比如上篇文章中提及的秒杀扣减库存的场景，是可以满足需求的。但是随着访问量的增加，一个tomcat难以支撑，这时候我们就需要集群部署tomcat，使用多个tomcat支撑起系统。

在上图中简单演化之后，我们部署两个Tomcat共同支撑系统。当一个请求到达系统的时候，首先会经过nginx，由nginx作为负载均衡，它会根据自己的负载均衡配置策略将请求转发到其中的一个tomcat上。当大量的请求并发访问的时候，两个tomcat共同承担所有的访问量。这之后我们同样进行秒杀扣减库存的时候，使用单体应用锁，还能满足需求么？

之前我们所加的锁是JDK提供的锁，这种锁在单个jvm下起作用，当存在两个或者多个的时候，大量并发请求分散到不同tomcat，在每个tomcat中都可以防止并发的产生，但是多个tomcat之间，每个Tomcat中获得锁这个请求，又产生了并发。从而扣减库存的问题依旧存在。这就是单体应用锁的局限性。那我们如果解决这个问题呢？接下来就要和大家分享分布式锁了。