云主机事务冲突如何解决?

讲个真事。去年我帮一家做社区团购的公司处理过一个怪问题。每天晚上八点左右，用户集中下单的高峰期，系统就会变得特别慢。不是那种彻底的崩溃，就是卡，提交订单要转好几圈，有时候转着转着就超时失败了。他们的技术负责人跟我描述的时候说了一句很形象的话，感觉就像数据库里有人在打架，谁都打不赢，谁都让不开。

我登录到云主机上，进了数据库一看，发现了一个规律。所有卡住的请求，都集中在几个热门商品的库存扣减操作上。几十个并发请求同时要修改同一行数据，但是事务之间的处理顺序出了问题，导致大量的锁等待和回滚。这就是典型的事务冲突。

今天我想跟你好好聊聊事务冲突这个话题。不是什么高深的理论，就是我这些年从各种“卡顿”“超时”“死锁”的故障里，一点一点摸出来的经验。

事务冲突到底是什么?用排队买票来理解

如果你去过火车站的售票窗口，就能理解事务冲突。假设只有一个窗口在卖票，前面排了十个人。每个人从开始买票到拿到票离开，就是一个“事务”。如果每个人买票都很快，三十秒一个，后面的人等一等也就轮到了。但如果第一个人买了五张票，每张票还要核对不同的优惠，磨蹭了五分钟，后面所有人的等待时间就都变长了。

更糟的情况是，如果买票的规则要求后面的人必须等前面的人拿到票才能开始问票价，那就更慢了。这就是事务冲突的一个直观缩影。

在云主机的数据库环境里，事务冲突通常发生在多个事务同时访问同一批数据的时候。一个事务正在修改某行数据，另一个事务也要修改或者读取这行数据，就必须等第一个事务提交或者回滚之后才能继续。这种等待本身是正常的数据库机制，问题出在当等待的时间太长，或者等待的关系形成了环路，系统就会卡住。

根据我这些年的观察，事务冲突大概有这么几种常见的形态。

第一种是读写冲突。一个事务正在修改某行数据，另一个事务要来读这行数据。在不同的隔离级别下，读事务可能被阻塞，也可能读到旧的数据。

第二种是写写冲突。两个事务都要修改同一行数据，后一个必须等前一个完成。这是最常见也最容易出问题的场景。

第三种是间隙冲突。一个事务锁住了一个范围的数据，另一个事务要往这个范围里插入新数据，被阻塞了。

第四种是死锁。两个事务互相持有对方需要的锁，形成了循环等待，谁也进行不下去。

理解这些类型是解决问题的第一步。因为不同类型的冲突，处理的方法完全不同。

案例一：热点行更新，大家挤在同一个门口

回到那家社区团购公司的问题。他们的业务场景其实很简单，每天晚上八点，一些爆款商品会集中开售。库存数量是有限的，比如某个商品只有一百件，但可能有五百个人同时来抢。这五百个请求都要去修改同一个商品的那一行库存记录。

这就是典型的热点行更新冲突。数据库的事务在修改这行数据之前需要先给它加锁。第一个到达的事务加锁成功，开始处理。剩下的四百九十九个事务都在等这把锁释放。如果第一个事务执行得很快，比如几十毫秒就提交了，那后面的请求排队的时间还可以接受。但如果第一个事务因为某些原因执行得慢，比如在事务里还做了别的耗时操作，后面的请求就会大面积超时。

我查看了他们扣减库存的代码，发现了问题所在。他们的事务里做了好几件事情。先锁库存，然后检查库存是否充足，然后扣减库存，然后插入一条订单记录，然后更新用户的积分，最后才提交事务。整个事务里做了五六个数据库操作，而且积分更新那块还调用了一个外部接口去同步数据到另一个系统。这个外部接口有时候会慢，导致整个事务的持续时间从几十毫秒飙升到几百甚至上千毫秒。

这就解释了为什么高峰期会卡。热点行的锁被一个慢事务拖住了，后面所有的请求都在排队，排队的队伍越来越长，最终导致超时。

解决的思路其实不复杂。核心原则就是一句话，把热点行锁的持有时间压缩到最短。

我们重新设计了扣减库存的逻辑。第一步，在事务开始之前，先通过一个轻量级的请求把库存锁定住。这个锁定的操作本身就是一个极其简短的update语句，只做一件事，把要扣减的数量从库存里减掉。这个update语句执行得非常快，锁持有时间只有几毫秒。第二步，update成功之后，再去做其他的操作，比如插入订单、更新积分等等。这些操作不需要再持有库存的行锁，即使慢一些，也不会影响其他的并发请求。

还有一个改进点是引入了本地队列。在应用服务器这一层，对于同一个商品的请求，先放进一个队列里排队，每次只放一个请求去操作数据库。这样做虽然本质上还是在排队，但避免了数据库层面的大量锁争用，整体吞吐量反而更高了，因为减少了锁等待和上下文切换的开销。

改动上线之后，晚上八点高峰期的订单超时率从百分之五左右降到了千分之一以下。用户感知到的明显变化就是，提交订单不再转圈了，点一下就成功。

案例二：读写冲突，一边在写一边在读

读写冲突这个事，说起来比写写冲突温和一些，但在某些场景下也会造成麻烦。我遇到过一家做报表分析的公司，他们的系统每天晚上会跑一批统计任务，从订单表里读取大量数据，计算出各种报表。这个统计任务通常要跑十几分钟。问题是，在统计任务运行期间，订单表上的正常写入操作变得越来越慢，有时候甚至超时失败。

原因在于数据库的隔离级别设置。他们用的是MySQL默认的Repeatable Read级别，在这个级别下，读操作会生成一个一致性读视图，但它不会阻塞写操作。听起来好像没问题，但问题出在他们统计任务里用了一些特殊的查询，这些查询在某些情况下会加锁。

具体来说，他们的统计任务里有一条语句是select for update，这条语句会对读取到的行加锁。这些行被锁住之后，业务上的写入操作想修改这些行，就只能等待。一个统计任务锁住了大量的行，业务写入操作大面积阻塞，就造成了冲突。

解决这个问题有几个思路。最简单的是把统计任务里面的select for update改成普通的select，如果不需要对读取的数据做后续的更新操作，根本不需要加锁。他们的统计任务确实只是读取数据做计算，不修改数据，所以直接去掉for update就解决了。

如果确实需要加锁的场景，可以考虑把统计任务的执行时间挪到业务低峰期，比如凌晨两三点，这时候没有多少写入操作，读写冲突就不会造成业务影响。还有一个常用的做法是把统计任务放到只读从库上去执行，主库只处理写入操作，这样读写分离之后，两边的操作互不干扰。

案例三：死锁，两个人互不相让

死锁这个问题，很多开发人员都遇到过，但遇到的时候往往一脸懵。我处理过的最典型的一个死锁案例，发生在一个转账系统里。用户A给用户B转账，同时用户B也给用户A转账，两个事务几乎是同时发生的。

每个转账事务的逻辑是，先锁住转出账户，再锁住转入账户，然后扣减和增加余额，最后释放锁。事务A锁住了账户A，等待账户B。事务B锁住了账户B，等待账户A。两个人都在等对方放手，就永远等下去了。数据库的死锁检测机制会在几毫秒到几十毫秒内发现这个循环等待，然后选择其中一个事务回滚，让另一个继续执行。

虽然数据库会自动处理死锁，但如果你的系统里频繁出现死锁，对用户体验是有影响的，因为每次死锁都意味着有一个事务会被回滚，用户需要重试。更重要的是，频繁死锁往往说明业务逻辑的设计有问题。

对于这个转账的例子，解决方案其实很简单。在所有的事务里，按照固定的顺序来访问资源。比如约定好，总是先锁住id较小的账户，再锁住id较大的账户。这样一来，事务A和事务B都会先尝试锁住账户A，因为账户A的id比账户B小。只有一个人能拿到账户A的锁，另一个人只能等待。拿到了账户A锁的那个人，再去锁账户B，就不会产生死锁了，因为锁的获取顺序是确定的。

还有一个更彻底的做法，对于转账这种场景，可以把扣减余额的操作设计成一种无锁的方式。用一个消息队列来异步处理转账请求，在消息消费的时候，通过版本号或者时间戳来做乐观锁控制。这样就从根源上避免了死锁的发生。

案例四：隔离级别引发的“隐形”冲突

还有一种事务冲突，表面上看不出任何锁等待，但系统的并发能力就是上不去。我帮一个做秒杀活动的客户排查过这个问题。他们的服务器配置不低，数据库也是高性能的云盘，但并发一上来，系统的TPS就上不去了，一直在几百左右徘徊，怎么压都压不上去。

后来我们把问题定位到了事务隔离级别上。他们用的是MySQL的Repeatable Read隔离级别，这个级别为了防止幻读，会在很多看似普通的查询上加间隙锁。他们的秒杀活动里有一个操作，需要先查询某个商品在最近一分钟内的订单数量，如果超过某个阈值就拒绝新的订单。这个查询使用了范围条件，在Repeatable Read级别下会产生间隙锁，锁住了一个区间。这导致后面很多原本不冲突的插入操作也被阻塞了，大大限制了系统的并发能力。

解决方案是把这个查询的事务隔离级别降低到Read Committed。在Read Committed级别下，不会产生间隙锁，只有行锁。而且对于秒杀这个场景，防止幻读并不是必须的，因为少量重复计数对业务的影响可以接受，或者说可以通过其他方式来补偿。调整隔离级别之后，同样的压测脚本，TPS从几百提升到了两三千，提升了将近十倍。

事务冲突的通用排查思路

说了这么多案例，我想总结一套面对事务冲突时的排查和处理思路。这套方法我自己用过很多次，每次都是按照这个节奏走的。

当你怀疑系统存在事务冲突的时候，第一步是确认冲突的类型。登录数据库，执行show engine innodb status，重点看TRANSACTION那一节的内容。这里面会列出当前活跃的事务、每个事务持有的锁以及正在等待的锁。如果存在死锁，LATEST DETECTED DEADLOCK部分会记录最近一次死锁的详细信息，包括涉及的事务、被回滚的是哪一个、以及导致死锁的SQL语句。这些信息对于定位问题极其宝贵。

第二步，根据冲突的类型选择对应的处理策略。如果是热点行更新冲突，优先考虑缩短事务持有锁的时间，把不必要的操作移出事务，或者引入排队机制。如果是读写冲突，评估一下读操作是否真的需要加锁，能不能放到从库上去执行。如果是死锁，检查事务里访问资源的顺序是不是固定的，能不能通过重新排序来避免循环等待。如果是间隙锁导致的冲突，考虑降低事务隔离级别，或者优化查询条件让它使用唯一索引。

第三步，如果事务冲突频繁发生，而且上面这些方法都试过了还是不行，那就要考虑更底层的架构调整了。比如把热点数据做拆分，原来的一行库存记录拆成十行，不同的用户请求分散到不同的分片上，冲突的概率就降低了十分之九。或者干脆把扣减库存这种操作从关系型数据库里移出来，放到Redis这样的缓存里来做，利用Redis单线程的特性天然地解决了并发冲突的问题。

第四步，不管是哪种冲突，监控和告警都是必不可少的。在数据库里设置锁等待超时的阈值，当锁等待时间超过一个合理的值比如五秒钟的时候，记录下当时的现场，发告警出来。有了告警才能及时发现问题的苗头，不至于等到用户大面积报错才知道出事了。

从冲突中学习，把坏事变成好事

回过头来看，每一次事务冲突的处理过程，其实都是一次对业务逻辑和系统设计的深度审视。为什么这里会有热点行，是不是可以把数据拆得更散一些。为什么事务里会有那么多操作，是不是可以拆分成几个独立的小事务。为什么频繁出现死锁，是不是多个服务之间访问数据库的顺序没有统一约定。

这些问题想清楚了，不仅解决了当前的事务冲突，整个系统的健壮性和可扩展性也会跟着提升一个台阶。我处理过的最成功的一个案例，经过一次热点行冲突的优化之后，系统的整体吞吐量提高了三倍，而且后来再也没有出现过类似的问题。