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只能做一件事情：等待一会儿，然后重试！ 如此循环下去，直到获得锁为止。
可是如果0x9527获得了锁，在执行的过程中TomcatA 挂掉了，那数据库记录一直存在，无人删除，那锁就永远也无法释放了！ 还得弄一个清理者， 清理那些过期没释放的锁， 这实在是太麻烦了。
Redis
这时候Redis说道：“千万别上MySQL的贼船！他的办法太笨重了，不就是找个第三方来保存锁的信息吗？ 用我的缓存多好！”
“Redis这小子操作的是内存，速度会快很多！” Tomcat B说道。
“对，MySQL不是给你们提供了一张表让你们插入数据吗？ 我这里不用那么麻烦，你们Tomcat的线程，都可以尝试到我的缓存中设置一个值，比如stock_lock=true， 谁先设置成功，谁就获得了锁，可以去扣减库存。”
“ 如果有多个线程去设置，你能保证只有一个成功，别的都失败吗？ ”
Redis拍拍胸脯： “绝对保证！”
(码农翻身老刘注：其实就是setnx命令了)
MySQL撇撇嘴：“和我的方案本质上是一样的。人家Tomcat 的线程对库存做了修改以后，也还得去解锁，去删除这个stock_lock。”
Redis说：“我这里还能设置过期时间，如果Tomcat A上线程获得了锁，然后Tomcat A挂掉了， 到了过期时间，我就可以自动把这个stock_lock删除，别的线程又可以获得锁了！”
“嗯，是比MySQL先进，并且速度更快，我们还是用这个锁吧。” 三个Tomcat都表示同意。
定期自动释放的问题
“且慢，这个自动删除过期的锁有问题啊 ！” MySQL突然反击。
“什么问题？” Redis没想到数据库老头儿还想负隅顽抗。
“假设Tomcat A上的0x9527获得了锁， 去执行扣减库存的操作，然后由于某种原因被阻塞了，阻塞的时间超过了过期时间，锁被你释放掉了，最终还是会出现不一致！”
“你这是吹毛求疵，绝对是小概率事件！” Redis叫道！
“再说了，用你的数据库方案，也得定期清理那些锁，道理是一样的。”
行锁
第二天， MySQL高兴得去找Tomcat：“兄弟们，我昨天晚上和Quartz(一个著名的定时执行框架)聊了半宿，他告诉了我一个新的用数据库实现分布式锁的办法， 行锁。”
“看到没有， 通过添加一个for udpate ，这个SQL语句会把这一行给锁定，就是获得了锁！ 只要事务一提交，这个行锁就自动释放了。”
“那没有获得锁的别的线程呢？ ”
“自然是阻塞住了，等到别的线程释放了行锁，它可以自动去获取，代码中都不用循环重试，你看，之前的方案都做不到这一点吧。” MySQL说道。
“那要是有个线程迟迟不释放行锁，会发生什么问题？” Tomcat最关心这个。
“那其他线程都会等待，并且占用着数据库连接不释放，嗯，如果连接被占用得过多，连接池就要出问题了......” MySQL底气不足了，这可是个致命的问题。
“哈哈，看你出的什么馊注意！还是用我的锁吧！” Redis笑道。
“那人家Quartz为什么可以用？”MySQL不死心。
“估计Quartz业务单一，并且锁释放得很快，不会出问题吧。”
CAS
正在这时，Node.js悄悄地走过来， 把数据库老头儿拉走了：“前辈，别给他们一般见识，不就是扣减库存吗，用啥分布式锁！， 咱们这么做：”
#old_num = 先获取现有的库存数量
#new_num = #old_num - 10
update stock set **stock_num** = **#new_num** where product_id=#product_id and **stock_num = #old_num**
MySQL眼前一亮， 是啊，每次把这个#old_num 作为条件传进去调用update语句，如果能成功，说明在这段时间内没有别的线程更新库存；
如果不成功，那就重新执行这三条语句，直到成功为止， 就这个么简单， 完全不用锁，真是太爽了。
过了几天，Tomcat他们也听说了这个方案， 惊讶地说：“这不就是我们Java常用的Compare And Set(CAS)吗？”
总结
与此同时，张大胖开始做总结：分布式锁和进程内的锁本质上是一样的。
1. 要互斥，同一时刻只能被一台机器上的一个线程获得。
2. 最好支持阻塞，然后唤醒，这样那些等待的线程不用循环重试。
3. 最好可以重入(本文没有涉及，参见《编程世界的那把锁》)
4. 获得锁和释放锁速度要快
对于分布式锁，需要找到一个集中的“地方”(数据库，Redis, Zookeeper等)来保存锁，这个地方最好是高可用的。
考虑到“不可靠的”分布式环境， 分布式锁需要设定过期时间
7. CAS的思想很重要。
扫一扫
704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
