并发批量写入：想给数据库“提速”，反而把业务搞崩了？

最新推荐文章于 2025-11-01 19:16:16 发布

原创最新推荐文章于 2025-11-01 19:16:16 发布 · 555 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

数据库同时被 2 个专栏收录

81 篇文章

订阅专栏

系统架构设计

34 篇文章

订阅专栏

做后端开发时，我们总想着“效率优先”——比如同步十万条日志、更新千个用户等级，下意识会用“并发批量写入”来节省时间。但实际场景中，很多团队都踩过同一个坑：本意是提速，结果却触发数据错乱、表锁阻塞、数据库宕机，最终业务停摆。

这背后的核心矛盾的是：并发批量写入看似“高效”，实则把数据库的“锁、资源、一致性”三大核心痛点无限放大。本文结合真实业务场景，拆解并发批量写入的4个致命陷阱，以及对应的破局方案。

一、陷阱1：数据一致性“崩坏”，业务逻辑直接出错

数据是业务的根基，但并发批量写入会直接击穿数据库的一致性防护，导致“超卖”“余额计算错误”等致命问题——这些错误往往隐蔽且难修复。

典型场景：库存超卖的噩梦

某电商做促销，商品A库存100件，运营同时触发两个“批量扣库存”任务：

任务A：给50个订单批量扣库存（每人1件），读取到库存=100，计算后待写入50；
任务A未提交时，任务B：给60个订单批量扣库存，也读取到库存=100，计算后待写入40；
最终两个任务都执行成功，库存变为40（而非100-50-60=-10，实际超卖了10件）。

问题根源：竞态条件+隔离级失效

竞态条件（Race Condition）：批量写入的“读取-计算-写入”是三步操作，并非原子性——两个任务读取到同一初始值，后续计算和写入必然出错；
隔离级别兜不住：即使数据库开了Repeatable Read（可重复读），批量写入的“大事务特性”会让隔离级失效：比如任务A批量更新到一半，任务B读取到“半完成数据”（如50条已更新，50条未更新），后续操作基于错误数据执行。

二、陷阱2：锁竞争“白热化”，一张表堵死整个业务

数据库靠“锁”保证安全，但并发批量写入会让锁从“保护盾”变成“绊脚石”——尤其是单表的并发批量，会触发“表锁”或“间隙锁风暴”，直接阻塞所有操作。

典型场景：订单表被锁，用户查不到订单

某外卖平台夜间同步“前一天订单状态”，同时启动两个并发批量任务：

任务1：批量更新“订单表”中“已完成”的订单（1000条）；
任务2：批量更新“订单表”中“已取消”的订单（800条）；

结果任务1触发了InnoDB的“锁升级”（行锁→表锁），任务2和所有用户的“查订单”请求全被阻塞——用户打开APP看不到订单，客服电话被打爆，持续了20分钟才恢复。

问题根源：锁范围失控

行锁升级为表锁：当批量写入涉及的行数过多（如超过1000行），InnoDB会自动将“行锁”升级为“表锁”——一旦表锁被持有，该表的读、写、改全被卡住；
间隙锁重叠：批量条件（如create_time < '2024-05-01'）会触发“Next-Key Lock”（间隙锁），若两个任务的条件有重叠（如另一个任务是create_time < '2024-05-02'），即使更新的是不同行，也会互相等待；
死锁概率陡增：若两个批量任务交叉锁表（如任务A锁订单表→用户表，任务B锁用户表→订单表），会直接触发死锁，数据库只能强制终止任务，导致数据部分丢失。

三、陷阱3：资源“耗尽”，数据库直接“罢工”

数据库的IO、内存、CPU是有限资源，并发批量写入相当于“多个重卡车同时抢一条小路”——瞬间把资源打满，整个数据库陷入“瘫痪”。

典型场景：日志同步打满磁盘IO

某 SaaS 平台做“用户操作日志”同步，同时启动3个并发批量插入任务（每个任务10万条日志）：

每个任务生成大量“脏页”（内存中未刷盘的数据），InnoDB为保证数据安全，触发“强制刷盘”；
磁盘IO使用率瞬间从20%飙升到100%，正常业务的“用户登录”“数据查询”因“IO等待”超时失败；
连接池也被耗尽（3个任务占了30个连接，默认连接池50个），新请求无法建立连接，平台直接报“503错误”。

问题根源：资源集中过载

IO瓶颈被击穿：批量写入的刷盘操作是IO密集型任务，单表的所有写入都指向同一物理文件（如MySQL的.ibd文件），并发会让IO请求排队拥堵；
内存缓存被挤占：批量写入会把缓冲池（InnoDB Buffer Pool）的空间占满，挤走正常业务的热点数据（如用户信息、商品缓存），导致查询只能读磁盘，形成“IO恶性循环”；
CPU被计算耗尽：批量任务的“字段脱敏”“索引更新”是CPU密集操作，多个任务叠加会让CPU使用率飙升，数据库连“简单查询”都无力处理。

四、陷阱4：故障恢复“难如登天”，业务中断时间翻倍

即使运气好没触发宕机，一旦并发批量任务失败（如断电、网络中断），后续的恢复工作会让团队崩溃——数据校验难、回滚时间长，业务中断时间被无限拉长。

典型场景：用户等级更新失败，回滚锁表1小时

某社区平台批量更新“用户等级”（10万用户），两个并发任务执行到一半时，服务器断电：

重启后，数据库需回滚两个未完成的大事务——每个事务回滚需要30分钟，期间持续持有“用户表”的锁，所有用户相关操作（注册、发帖、评论）全被阻塞；
回滚完成后，还需对比“任务日志”和“表数据”，逐行校验哪些用户等级更新成功、哪些失败——10万条数据校验花了2小时，业务中断近3小时。

问题根源：故障影响高度集中

大事务回滚耗时：批量写入对应“大事务”，回滚时需撤销所有已执行操作，且回滚期间会持续锁表；
数据校验无捷径：并发任务的错误范围高度集中（如全在“用户表”），无法通过“跨表关联”快速定位问题，只能逐行对比，效率极低。

破局之道：不是“禁止”，而是“科学管控”

并发批量写入并非“洪水猛兽”，关键是避开“无序并发”，用以下5个方案实现“效率与安全的平衡”：

1. 串行化：用队列把“并发”转“串行”

核心逻辑：让批量任务排队执行，避免锁竞争。

实现方式：用 Kafka/RabbitMQ 搭建任务队列，所有批量写入任务（如扣库存、更等级）先进入队列，消费者按“FIFO”（先进先出）顺序执行；
效果：彻底避免锁竞争和数据一致性问题，缺点是牺牲部分效率，但换来了业务稳定。

2. 分批拆分：把“大任务”拆成“小批次”

核心逻辑：减少单次任务的资源占用和锁范围。

实现方式：把“1次写10万条”拆成“100次写1000条”，每次任务执行后释放资源；
注意：批次大小需根据数据库性能调整（如MySQL建议单次批量不超过2000条），避免单次任务仍触发锁升级。

3. 错峰执行：避开业务高峰期

核心逻辑：在资源空闲时执行批量任务，不影响正常业务。

实现方式：通过定时任务（如XXL-Job、Quartz）把批量写入安排在“凌晨2-4点”（业务低峰期），同时监控数据库资源（IO、CPU、连接数），超标立即暂停；
适合场景：日志同步、历史数据更新等非实时需求。

4. 乐观锁：用“版本号”避免竞态条件

核心逻辑：不依赖数据库锁，靠业务逻辑保证一致性。

实现方式：给表加version字段，批量更新时加条件WHERE ... AND version = 当前版本，更新成功后version+1；
示例：扣库存时用UPDATE stock SET num = num-1, version = version+1 WHERE goods_id = ? AND version = ?，若版本不匹配则重试，避免超卖。