数据库锁那些事儿，聊聊怎么快点搞定海量数据处理问题

综合自多位资深后端工程师的博客分享、技术社区如Stack Overflow的常见问题讨论、以及《高性能MySQL》等经典技术书籍中的核心思想）

今天咱们就来聊聊数据库锁那些事儿,特别是当数据量像滚雪球一样越滚越大时，怎么才能不让“锁”成为拖慢整个系统的绊脚石，你可以把数据库想象成一个热闹的公共卫生间，锁就是那个门闩，一个人进去办事，把门闩插上，别人就得在外面等着，这本来是为了安全，避免尴尬，但如果一个人占着坑位太久，或者等着上厕所的人排成了长龙，那整个队伍的效率就堪忧了，我们的目标就是，既保证安全（数据没错），又让大家能快点解决问题（高并发）。

得知道锁有哪些种类,不然出了问题都不知道是哪儿堵住了，最常见的两种锁是“共享锁”和“排他锁”，这名字听着唬人，其实很简单，共享锁就像是卫生间里的一个小隔间，很多人都可以同时进去“读”，互不干扰，很多人同时查询一件商品的库存，这个操作上个共享锁就行了，大家可以一起查，而排他锁就厉害了，它像是一个单间大马桶，一个人进去“写”数据（比如下单减库存），必须把门反锁，其他无论是想读还是想写的人，通通都得在外面候着，这个排他锁，就是最容易引起“堵塞”的元凶。

当数据量小、用户少的时候，这种锁机制没啥问题，大家稍微等一下就好了，但数据变成海量，用户请求像潮水一样涌来时，问题就大了，最让人头疼的就是“锁竞争”，想象一下，双十一零点，成千上万的人同时抢购一款热门手机，每个人都想给库存减一，每个减一的动作都需要拿到那个库存数据的排他锁，这就好比一万个人同时冲向同一个单间卫生间，结果只能有一个人进去，其他9999个人全在门口干等着，系统可不就卡死了嘛。

那怎么办呢？总不能让大家都不买了吧，这时候就得想办法“快点搞定”。

第一招,也是最重要的一招，叫“缩小锁的范围”，专业点叫降低锁的粒度，别动不动就锁整个表，那相当于把整个商场的大卫生间都给封了，谁也别想用，我们要争取只锁住需要改的那一小撮数据，在更新数据时，尽量使用非常精确的条件，让数据库引擎只锁住那一行数据（行级锁），而不是锁住整个表（表锁），现代的数据库如MySQL的InnoDB引擎，通常都支持行级锁，这比老式的表锁要先进得多，这就好比把大卫生间改造成了很多个小隔间，一个人用其中一个，不影响别人用其他的。

第二招,叫“缩短锁的时间”，占着茅坑不拉屎最招人恨，在写数据库操作代码的时候，一定要牢记：把事务弄得尽可能短小精悍，什么事务？就是把几个数据库操作打包成一个不可分割的单元，要么全成功，要么全失败，在一个事务里，锁是在需要的时候才加上，直到事务提交或回滚才会释放，千万不要在事务里执行一些慢吞吞的操作，比如在循环里一条一条地处理数据、或者去调用外部的网络服务，应该先在外面把所有的计算和准备工作都做好，然后进入事务，快速完成数据的增删改查，然后立刻提交事务，释放锁，这样，锁在你手里的时间就短了，别人就能更快地拿到锁。

第三招,有点“绕道而行”的意思，就是使用“乐观锁”，这招特别适合那种“读多写少”的场景，乐观锁的想法很乐观：我觉得大概率不会有人跟我同时改同一条数据吧？我读数据的时候，先不加锁，顺便记下这数据的一个版本号（或者时间戳），当我准备更新的时候，我再检查一下，这个版本号是不是还是我当初记下的那个？如果是，说明中间没人动过，那我就放心地更新，同时把版本号加一，如果不是，说明有别人已经改过了，那我的更新就放弃，返回给用户一个错误信息，宝贝太火爆了，请重试”，这样做的好处是，在读取的时候完全不加锁，大大提高了并发读的能力，虽然写的时候可能会失败需要重试，但相比那种一直傻等锁的方式，整体吞吐量可能更高，这就像你去超市买东西，看到货架上最后一个，你直接拿到手里（记下版本号），去结账时如果扫码没问题（版本号对得上），就是你的了，如果有人比你手快先结了账，系统会告诉你“商品已售罄”，你再去拿别的就行了。

第四招,是从架构层面想办法，叫做“读写分离”，把数据库分成一个主库（负责写）和多个从库（负责读），所有的写操作都去到主库，读操作则分散到各个从库上去，这样，写操作带来的锁竞争只发生在主库上，而大量的读请求可以由从库来分担，从库的数据是主库同步过来的，虽然有一点点延迟，但对于很多不要求绝对实时性的查询（比如查看订单列表、查询商品信息）已经完全够用了，这相当于给商场建了多个分卫生间，主卫生间负责“维护”（写），分卫生间负责接待大部分“顾客”（读），压力一下子就分散了。

还有一个终极武器,排队与异步”，对于一些可以稍后完成的操作，不要都在数据库事务里同步完成，比如用户下单后，扣减库存和生成订单必须在事务里同步完成，但后续的发短信通知、更新排行榜、记录复杂的日志等操作，完全可以放到一个消息队列里，由后台的任务慢慢去处理，这样就能极大地缩短核心事务的执行时间，从而快速释放数据库锁。

搞定海量数据下的锁问题,核心思路就是：精确定位、速战速决、乐观应对、分而治之、能拖就拖（指非核心操作异步化），没有一劳永逸的银弹，你需要根据自己业务的特点，比如是读多还是写多，对数据一致性要求有多高，来灵活组合使用这些方法，希望这些大白话的讲解，能帮你对数据库锁有个直观的理解，在遇到性能瓶颈时，能多几个解决问题的思路。