单体应用锁的局限性在进入实战之前简单和大家粗略聊一下互联网系统中的架构演进。
我看愣了,MySQL 还能实现分布式锁?在互联网系统发展之初,消耗资源比较小,用户量也比较小,我们只部署一个 tomcat 应用就可以满足需求。一个 tomcat 我们可以看做是一个 jvm 的进程,当大量的请求并发到达系统时,所有的请求都落在这唯一的一个 tomcat 上,如果某些请求方法是需要加锁的,比如上篇文章中提及的秒杀扣减库存的场景,是可以满足需求的。但是随着访问量的增加,一个 tomcat 难以支撑,这时候我们就需要集群部署 tomcat,使用多个 tomcat 支撑起系统。
在上图中简单演化之后,我们部署两个 Tomcat 共同支撑系统。当一个请求到达系统的时候,首先会经过 nginx,由 nginx 作为负载均衡,它会根据自己的负载均衡配置策略将请求转发到其中的一个 tomcat 上。当大量的请求并发访问的时候,两个 tomcat 共同承担所有的访问量。这之后我们同样进行秒杀扣减库存的时候,使用单体应用锁,还能满足需求么?
之前我们所加的锁是 JDK 提供的锁,这种锁在单个 jvm 下起作用,当存在两个或者多个的时候,大量并发请求分散到不同 tomcat,在每个 tomcat 中都可以防止并发的产生,但是多个 tomcat 之间,每个 Tomcat 中获得锁这个请求,又产生了并发。从而扣减库存的问题依旧存在。这就是单体应用锁的局限性。那我们如果解决这个问题呢?接下来就要和大家分享分布式锁了。
分布式锁什么是分布式锁?
那么什么是分布式锁呢,在说分布式锁之前我们看到单体应用锁的特点就是在一个 jvm 进行有效,但是无法跨越 jvm 以及进程。所以我们就