别吵吵，分布式锁也是锁

 Tomcat的锁

Tomcat是这个系统的核心组成部分， 每当有用户请求过来，Tomcat就会从线程池里找个线程来处理，有的执行登录，有的查看购物车，有的下订单，看着属下们尽心尽职地工作，完成人类的请求，Tomcat就很有成就感。

与此同时，它也很得意，所有的业务逻辑尽在掌握。MySQL算啥!不就是一个保存数据的地方吗? Redis算啥!不就是一个加快速度的缓存吗?

没有他们，我也能找到替代品，而我不可替代的， Tomcat经常这么想。

昨天MySQL偶然说起隔壁机器入驻了一个叫做Node.js的家伙，居然只用一个线程来执行JavaScript代码，实现各种业务逻辑，JavaScript也能到后端来?还用回调? 这不是胡闹吗?不过得小心，别被他把业务都给抢走了。

想到此处，Tomcat立刻去查看各个线程活干得怎么样，有没有人故意偷懒。

线程0x9527和0x7954又在吵架了，原因非常简单，他们俩都去做扣减库存的操作：读取库存，修改库存，写回数据库。

线程的并发执行导致三个操作交织在了一起，最后数据出现了不一致。

Tomcat说：“你们怎么搞的，为什么要把库存读出来，直接update 库存不行吗? 让MySQL老头儿去保证正确性。要学会甩锅啊!”

0x7954回答道：“没办法，张大胖的代码就是这么写的，好像是业务要求的，扣减库存之前要检查库存够不够。”

Tomcat一阵牙疼， 不由得想起了Redis的处理办法， 对于每个读写缓存的请求，Redis都把他们给排成了队，用一个线程挨个去处理，肯定没有这个并发的问题了。

可是自己这里不行啊，访问数据库是极慢的操作，如果只用一个线程，一个个地处理请求，所有的请求都得等待，人类会急死的。

没办法，Tomcat扔给他们俩一个Java对象：“这是一把锁，以后谁先抢到谁才能执行扣减库存的三个操作。”

“如果抢不到怎么办?”

“阻塞等待，别人释放了锁，JVM自然会唤醒你，然后再去抢! 什么时候抢到，什么时候执行。”

分布式的锁

张大胖觉得有点不对劲， 这几天程序执行怎么有点儿慢了呢?

他还以为是机器性能不够，就申请了几台新机器，又安装了几个Tomcat，组成了一个集群。

这下可好，三个Tomcat， 每个Tomcat都有一把锁来控制对库存的访问。

在Tomcat这个JVM进程内部，同一个时刻只有一个幸运儿线程可以扣减库存，可是现在有三个Tomcat，出现了三个幸运儿。

这三个幸运儿在扣减库存的时候，仍然会出现0x7954和0x9527那样的错误，只不过现在他们互不知晓，连吵架的机会都没有了。

三个Tomcat都觉得头大，在这个分布式的环境中，多个进程在运行，原来那种进程内的锁已经失效，当务之急是找一个客观、公正、独立的第三方来实现锁的功能。

MySQL提议： “到我这里来找锁啊!”

“你那里能提供一个锁服务? 暴露出来让我们使用? ” Tomcat A问道。

“不不，不是一个锁服务，我给你们一个数据库表，这个表中的字段lock_name有个唯一性约束。”

“你的意思是，我们的线程每次想获得锁的时候，都去数据库插入一条数据? ” Tomcat A 反映很快。

insert into locks(lock_name,...) values('stock',...); 

“对啊，我的唯一性约束只能保证一个成功，其他的都失败，就相当于获得锁了。 当然那个线程的操作完成以后，需要释放锁。”

delete from locks where lock_name='stock' 

这倒是一个简单的办法， 但也是一个重量级的办法：每次获得锁都得访问一次数据库!

假设来自TomcatA的0x9527捷足先登，插入了一条数据，获得了锁， 那来自Tomcat B的0x7954操作肯定失败，这时候0x7954该怎么办? 能阻塞等待TomcatB来唤醒他吗? 不行，因为连TomcatB 都不知道0x9527什么时候操作完成， 除非MySQL来通知各个Tomcat， 这是肯定不行的。

那0x7954@TomcatB只能做一件事情： 等待一会儿，然后重试! 如此循环下去，直到获得锁为止。