大家好我是小耶写功课只是为了我踩过的坑你们别再踩了上周讲了MySQL参数调优有读者问“参数都调了但秒杀的时候一条UPDATE库存的SQL还是卡得要死怎么办”这个问题问到点子上了。参数调优能解决的是“数据库跑得不够快”的问题但秒杀场景的瓶颈往往不在参数在行锁。成千上万个请求同时抢同一行库存数据就像几十个人挤一扇门——门一次只能过一个人后面的人全在排队。这种场景下哪怕你的数据库参数调得再好行锁本身也成了天花板。今天把这个场景拆开讲一遍一条UPDATE语句在秒杀时到底发生了什么、为什么会卡住、以及怎么让它快起来。一、问题还原一行UPDATE是怎么拖垮整个数据库的假设有一个秒杀系统商品ID1001库存100件。扣库存的SQL长这样sqlUPDATE inventory SET stock stock - 1 WHERE product_id 1001 AND stock 0;5000个并发请求同时执行这条SQL。你以为数据库会并行处理不会。同一时刻只能有一个事务持有这行的行锁其他4999个请求全部在排队等锁释放。排队本身就有代价锁等待超时默认innodb_lock_wait_timeout50秒等不到就报错死锁检测消耗CPUInnoDB要不断检查这些等待会不会形成死锁大量并发时死锁检测本身就能把CPU吃满连接池耗尽大量连接卡在“等锁”状态新请求进不来一句UPDATE就能把整个DB拖垮不是危言耸听。二、为什么分库分表救不了热点行有人会说“把库存拆分到多个分片不就行了吗”库存拆分确实能解决一部分问题但效果有限。把商品库存拆成10个分片每个分片承担1/10的流量——扣减逻辑变成了“先找有库存的分片再扣”引入了额外的路由逻辑和跨分片协调开销。分库分表解决的是“总量太大”的问题不是“单行太热”的问题。热点行永远只有一个——商品ID1001这行数据。拆了表这行数据还在某个分片里锁竞争依然存在。真正要解决的是“怎么让同一行数据被多个请求同时访问时系统还能扛得住”。三、数据库层的优化方案方案一热点更新排队机制云厂商的MySQL分支如腾讯云TXSQL、阿里云PolarDB提供了热点更新排队功能。核心思路是事务在加锁前先判断是否为热点行如果是则进入等待队列前一个事务提交后才唤醒下一个。效果把随机争抢变成有序排队减少死锁检测开销。实测可提升1.5-10倍吞吐量。代价需要特定版本支持MySQL 5.7 20250330或8.0 20241001且仅支持主键和唯一键的热点行。方案二Inventory Hint阿里内核补丁阿里自研的内核补丁通过特殊的hint语法优化热点行并发更新。核心思想是让热点更新“排队”而不是“打架”减少行级锁等待智能排队机制减少B树遍历Row Cache缓存优化效果结合Inventory Hint单行热点更新性能可提升5倍以上。四、业务层的优化策略策略一库存拆分分散锁压力把100件库存拆成10个库存分片stock_1到stock_10每个分片10件。扣减时随机选一个分片扣。优点实现相对简单适合中小规模场景。锁粒度降低并发能力提升。缺点需要处理分片库存不均的问题——某个分片扣完了其他分片还有库存路由逻辑变复杂。策略二Redis预扣减 异步落库秒杀流量先打到Redis在Redis中完成库存预扣减真正成功下单后再异步写入MySQL。流程请求→Redis扣库存原子操作→返回成功→异步写入MySQL落库优点MySQL的写入压力从每秒数万降到每秒数百缺点需要处理Redis和MySQL的数据一致性最终一致性方案策略三请求合并组提交将同一热点行的多个更新请求在应用层合并成一次批量更新。比如100个请求要各扣1件库存合并成一条UPDATE inventory SET stock stock - 100 WHERE product_id 1001 AND stock 100。优点100次行锁变成1次缺点需要业务允许批量扣减且要处理“部分成功”的复杂逻辑。五、一个真实的优化案例某电商平台秒杀场景单商品库存扣减的TPS峰值约2000MySQL的CPU使用率长期在85%以上偶尔冲到100%导致服务超时。优化前单条UPDATE直接怼数据库500并发下平均响应时间约500msP99超过2秒。优化路径第一步启用热点更新排队机制。相同配置下TPS从2000提升到3500CPU从85%降到60%。第二步引入Redis预扣减。MySQL的写入压力从每秒3500降到每秒约500CPU降到30%以下。第三步库存拆分。将热点商品的库存拆成5个逻辑分片进一步降低单行锁竞争。优化后500并发下平均响应时间降到5msP99控制在20ms以内。系统扛住了10倍于之前的流量。六、总结热点行更新是秒杀场景下的“头号杀手”但它的本质问题很简单——行锁是串行的高并发下必然成为瓶颈。优化路径的优先级优先级方案适用场景实施成本1Redis预扣减 异步落库所有秒杀场景中等2热点更新排队机制云数据库环境低开启参数即可3库存拆分中小规模低4请求合并/组提交批量扣减场景中等5Inventory Hint阿里系数据库低需内核支持核心思路就一句话让热点数据“绕开”数据库或者让数据库“排队”处理热点请求。直接硬扛行锁再好的硬件也扛不住。小耶在手SQL 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~
大家好我是小耶写功课只是为了我踩过的坑你们别再踩了上周讲了MySQL参数调优有读者问“参数都调了但秒杀的时候一条UPDATE库存的SQL还是卡得要死怎么办”这个问题问到点子上了。参数调优能解决的是“数据库跑得不够快”的问题但秒杀场景的瓶颈往往不在参数在行锁。成千上万个请求同时抢同一行库存数据就像几十个人挤一扇门——门一次只能过一个人后面的人全在排队。这种场景下哪怕你的数据库参数调得再好行锁本身也成了天花板。今天把这个场景拆开讲一遍一条UPDATE语句在秒杀时到底发生了什么、为什么会卡住、以及怎么让它快起来。一、问题还原一行UPDATE是怎么拖垮整个数据库的假设有一个秒杀系统商品ID1001库存100件。扣库存的SQL长这样sqlUPDATE inventory SET stock stock - 1 WHERE product_id 1001 AND stock 0;5000个并发请求同时执行这条SQL。你以为数据库会并行处理不会。同一时刻只能有一个事务持有这行的行锁其他4999个请求全部在排队等锁释放。排队本身就有代价锁等待超时默认innodb_lock_wait_timeout50秒等不到就报错死锁检测消耗CPUInnoDB要不断检查这些等待会不会形成死锁大量并发时死锁检测本身就能把CPU吃满连接池耗尽大量连接卡在“等锁”状态新请求进不来一句UPDATE就能把整个DB拖垮不是危言耸听。二、为什么分库分表救不了热点行有人会说“把库存拆分到多个分片不就行了吗”库存拆分确实能解决一部分问题但效果有限。把商品库存拆成10个分片每个分片承担1/10的流量——扣减逻辑变成了“先找有库存的分片再扣”引入了额外的路由逻辑和跨分片协调开销。分库分表解决的是“总量太大”的问题不是“单行太热”的问题。热点行永远只有一个——商品ID1001这行数据。拆了表这行数据还在某个分片里锁竞争依然存在。真正要解决的是“怎么让同一行数据被多个请求同时访问时系统还能扛得住”。三、数据库层的优化方案方案一热点更新排队机制云厂商的MySQL分支如腾讯云TXSQL、阿里云PolarDB提供了热点更新排队功能。核心思路是事务在加锁前先判断是否为热点行如果是则进入等待队列前一个事务提交后才唤醒下一个。效果把随机争抢变成有序排队减少死锁检测开销。实测可提升1.5-10倍吞吐量。代价需要特定版本支持MySQL 5.7 20250330或8.0 20241001且仅支持主键和唯一键的热点行。方案二Inventory Hint阿里内核补丁阿里自研的内核补丁通过特殊的hint语法优化热点行并发更新。核心思想是让热点更新“排队”而不是“打架”减少行级锁等待智能排队机制减少B树遍历Row Cache缓存优化效果结合Inventory Hint单行热点更新性能可提升5倍以上。四、业务层的优化策略策略一库存拆分分散锁压力把100件库存拆成10个库存分片stock_1到stock_10每个分片10件。扣减时随机选一个分片扣。优点实现相对简单适合中小规模场景。锁粒度降低并发能力提升。缺点需要处理分片库存不均的问题——某个分片扣完了其他分片还有库存路由逻辑变复杂。策略二Redis预扣减 异步落库秒杀流量先打到Redis在Redis中完成库存预扣减真正成功下单后再异步写入MySQL。流程请求→Redis扣库存原子操作→返回成功→异步写入MySQL落库优点MySQL的写入压力从每秒数万降到每秒数百缺点需要处理Redis和MySQL的数据一致性最终一致性方案策略三请求合并组提交将同一热点行的多个更新请求在应用层合并成一次批量更新。比如100个请求要各扣1件库存合并成一条UPDATE inventory SET stock stock - 100 WHERE product_id 1001 AND stock 100。优点100次行锁变成1次缺点需要业务允许批量扣减且要处理“部分成功”的复杂逻辑。五、一个真实的优化案例某电商平台秒杀场景单商品库存扣减的TPS峰值约2000MySQL的CPU使用率长期在85%以上偶尔冲到100%导致服务超时。优化前单条UPDATE直接怼数据库500并发下平均响应时间约500msP99超过2秒。优化路径第一步启用热点更新排队机制。相同配置下TPS从2000提升到3500CPU从85%降到60%。第二步引入Redis预扣减。MySQL的写入压力从每秒3500降到每秒约500CPU降到30%以下。第三步库存拆分。将热点商品的库存拆成5个逻辑分片进一步降低单行锁竞争。优化后500并发下平均响应时间降到5msP99控制在20ms以内。系统扛住了10倍于之前的流量。六、总结热点行更新是秒杀场景下的“头号杀手”但它的本质问题很简单——行锁是串行的高并发下必然成为瓶颈。优化路径的优先级优先级方案适用场景实施成本1Redis预扣减 异步落库所有秒杀场景中等2热点更新排队机制云数据库环境低开启参数即可3库存拆分中小规模低4请求合并/组提交批量扣减场景中等5Inventory Hint阿里系数据库低需内核支持核心思路就一句话让热点数据“绕开”数据库或者让数据库“排队”处理热点请求。直接硬扛行锁再好的硬件也扛不住。小耶在手SQL 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
