mysql居然还能实现分布式锁的方法(2)-木庄网络博客

8080的console日志情况：

11:49:41 INFO 16360 --- [nio-8080-exec-2] c.k.d.service.MySQLOrderService : 进入了方法
11:49:41 INFO 16360 --- [nio-8080-exec-2] c.k.d.service.MySQLOrderService : 拿到了锁

8081的console日志情况：

11:49:48 INFO 17640 --- [nio-8081-exec-2] c.k.d.service.MySQLOrderService : 进入了方法

通过日志情况，两个不同的jvm，由于第一个到8080的请求优先拿到了锁，所以8081的请求就处于等待锁释放才会去执行，这说明我们的分布式锁生效了。
再看一下完整执行之后的日志情况：

8080的请求：

11:58:01 INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : 进入了方法
11:58:01 INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : 拿到了锁
11:58:07 INFO 15380 --- [nio-8080-exec-1] c.k.d.service.MySQLOrderService          : http-nio-8080-exec-1库存数1

8081的请求：

11:58:03 INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : 进入了方法
11:58:08 INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : 拿到了锁
11:58:14 INFO 16276 --- [nio-8081-exec-1] c.k.d.service.MySQLOrderService          : http-nio-8081-exec-1库存数0
11:58:14 ERROR 16276 --- [nio-8081-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.Exception: 商品100100仅剩0件，无法购买] with root cause

java.lang.Exception: 商品100100仅剩0件，无法购买
at com.kd.distribute.service.MySQLOrderService.createOrder(MySQLOrderService.java:61) ~[classes/:na]

很明显第二个请求由于没有库存，导致最终购买失败的情况，当然这个场景也是符合我们正常的业务场景的。最终我们数据库的情况是这样的：

很明显，我们到此数据库的库存和订单数量也都正确了。到此我们基于数据库的分布式锁实战演示完成，下面我们来归纳一下如果使用这种锁，有哪些优点以及缺点。

优点：简单方便、易于理解、易于操作。
缺点：并发量大的时候对数据库的压力会比较大。
建议：作为锁的数据库和业务数据库分开。

写在最后

对于上述数据库分布式锁，其实在我们的日常开发中用的也是比较少的。基于redis以及zk的锁倒是用的比较多一些，本来老猫想把redis锁以及zk锁放在这一篇中一起分享掉，但是再写在同一篇上面的话，篇幅就显得过长了，因此本篇就和大家分享这一种分布式锁。源码大家可以在老猫的github中下载到。地址是：https://github.com/maoba/kd-distribute

到此这篇关于mysql居然还能实现分布式锁的方法的文章就介绍到这了,更多相关mysql 分布式锁内容请搜索

更多相关Mysql内容来自木庄网络博客

标签：Mysql

返回前面的内容