拼团锁单接口性能优化实战：从780ms到45ms的架构演进

1. 先说结论这次优化我们做了什么去年Q3我们平台的爆款拼团活动一上线就瘫了。运营在群里喊活动页面打不开技术告警群被数据库连接池打满的消息刷屏客户端图片加载的速度慢到不忍直视。我作为这个项目的主力开发从上午排查到半夜最后把拼团锁单接口从平均响应780ms压到了45ms系统支持的并发量从一碰就崩提升到稳定扛住每秒5000个请求。这篇文章就是这次优化的完整复盘把我在过程中踩过的坑、做过的取舍、验证过的方案都写出来希望能帮到正在被类似问题折磨的同行。先说清楚拼团锁单接口是干什么的。用户点下参团按钮服务端要依次完成检查拼团活动是否在进行中、校验用户是否有参团资格、确认拼团名额还有没有剩余、锁定一个名额、扣减库存、生成拼团记录和订单最后把结果返回给用户。这一串操作在业务低峰期没有任何压力但一旦赶上限时限量的爆款拼团几十万用户同时挤进来锁单接口就变成了整个系统最脆弱的环节。这篇文章不只写怎么调优一个接口而是从业务建模、存储层选型、并发控制、削峰异步、压测验证到线上容灾把一条链路是怎么从能跑变成能扛讲透。如果你正在做电商后端尤其是接触过秒杀、拼团、抢购、预约这类高并发场景不管用的哪套技术栈这里面的思路都能直接套用。哪怕你现在还没遇到性能问题提前搞懂这套优化方法也是值得的。2. 为什么慢先找准瓶颈再动手2.1 原始的锁单链路长什么样改造之前锁单接口走的是最朴素的同步事务模型核心逻辑用伪代码描述大概是这样的我把业务无关的细节都省略了Transactional(rollbackFor Exception.class) public LockResult lockOrder(Long grouponId, Long userId) { Groupon groupon grouponDao.selectById(grouponId); if (groupon.getStatus() ! 1) { return LockResult.fail(活动已结束); } Stock stock stockDao.selectByGrouponId(grouponId); if (stock.getRemain() 0) { return LockResult.fail(名额已满); } stock.setRemain(stock.getRemain() - 1); stockDao.updateById(stock); GrouponRecord record new GrouponRecord(); record.setGrouponId(grouponId); record.setUserId(userId); record.setStatus(0); grouponRecordDao.insert(record); Order order new Order(); order.setUserId(userId); order.setGrouponId(grouponId); orderDao.insert(order); return LockResult.success(order); }这段代码如果放在低并发的内部管理工具里其实没什么问题。但放到抢购场景下它有三个致命伤。第一整个锁单过程被包在一个大事务里。从第一次查活动开始到订单插入成功提交事务数据库连接被占用的时间可能长达几十甚至上百毫秒。行锁要等到事务提交才释放高峰期每个请求都握着连接和锁不放连接池很快被耗干。第二查库存再改库存是典型的先读后写模式。两个请求同时进来都读到剩余库存为1然后各自减一都认为自己成功了。最后库存变成-1订单却生成了这就是超卖。很多人第一反应是给库存行加select for update锁但那样只会让锁等待更加严重。第三每次锁单要查询多次数据库。活动表、库存表、拼团明细表、订单表各访问一次一个请求的数据库往返次数至少4次。正常流量下多几次查询无非慢一点高并发下连接数、CPU、磁盘IO的消耗会呈线性放大。2.2 用监控和压测把瓶颈钉死在动手改造前我们并没有凭感觉猜问题而是先复现、再分析。当时线上监控数据已经把问题暴露得很明显锁单接口平均响应时间780msP99达到1.6s数据库连接池80%以上的连接处于等待状态应用线程池里的线程几乎全部阻塞在DAO调用上。我们把接口链路拆成三块看网关层、应用层、存储层。网关层当时没有限流流量全部透传应用层线程池被数据库等待拖死存储层的库存表和拼团明细表在高峰时锁等待次数每分钟冲到上千次。单纯看数据会觉得数据库太慢但深挖后发现真正的问题是应用把数据库用得太笨——无效查询太多、事务持锁时间太长、没有缓存也没有队列把压力全部甩给了数据库。随后做了两轮压测。第一轮按生产配置直接压发现接口在并发100时TPS只有215错误率开始抬头把并发加到300数据库连接池直接被击穿大量报错刷屏。这一轮压测得到的数值不只是给老板看的优化前数据更重要的是帮我们定下了明确目标TPS至少提升十倍平均响应时间降到100ms以内P99控制在200ms以内错误率趋近于零。后面的所有优化动作都以这三个指标为标尺。3. 第一板斧数据库交互从笨重改到精准3.1 用一条原子UPDATE解决超卖这里有一个很多人都会纠结的点库存扣减到底用乐观锁还是悲观锁先说结论我们最终选了数据库的原子UPDATE语句既没用select for update也没用version乐观锁。原子UPDATE的写法非常简洁UPDATE t_stock SET remain remain - 1, version version 1 WHERE groupon_id #{grouponId} AND remain 1这条SQL的原子性由数据库保证WHERE remain 1确保扣减不会把库存扣成负数SET remain remain - 1在并发环境下只会有一个事务能成功更新这一行其他并发事务要么等待要么影响行数为0。应用层只需要判断影响行数返回1说明锁单成功返回0说明库存不足或已被抢完直接返回失败。为什么不推荐select for update它确实能锁住行但锁的释放依赖于整个事务的提交。如果事务里还有其他耗时操作比如插入订单、调用外部接口库存行锁被持有的时间就会很长。高并发下所有请求堵在同一行上等锁性能会非常差。原子UPDATE把检查库存扣减库存合并成一次操作锁持有时间极短而且不依赖后续业务操作的结果。为什么也弃用了乐观锁乐观锁是先读版本号、更新时再比对版本号高并发场景下会大量失败重试。想象一下100个请求同时读到version1只有1个能成功更新剩下99个都要重试白白给数据库增加成倍的无效压力。原子UPDATE用一条SQL解决问题是更务实的方案。3.2 把订单和明细插入挪出关键事务再回到那个大事务。库存扣减只需要一条UPDATE就能完成但之前的实现把查活动、扣库存、插拼团明细、插订单全部包在一个事务里。一旦最后插入订单失败整个事务回滚库存也被释放逻辑上没问题但代价是行锁持有时间过长。我们做的第一件事是缩小事务边界锁单接口的锁阶段只负责原子扣减库存、写入一条拼团占位记录这两个操作放进一个短事务提交后立刻返还数据库连接。订单的实际生成放到后面异步执行。这跟很多人的直觉相反——但在抢购场景下用户第一时间的诉求其实是我参团成功了吗而不是我的订单立刻出现在列表里。占位记录也做了设计不直接插入正式的订单表而是先插入一张拼团记录表状态为锁定中字段里带上幂等键。后续异步任务负责生成订单把状态推进到已创建。如果异步任务失败通过定时补偿任务扫描超时的锁定记录重新生成订单如果用户一直没支付延迟队列负责释放名额。这套状态机在后面第五节展开讲。3.3 索引优化和连接池参数调整这个环节经常被忽略但收益同样明显。原来的库存表只有主键索引活动ID这一列没有索引导致每次按活动查库存都要走全表扫描。我们给库存表的活动ID加了唯一索引同时给拼团记录表加了一个联合索引用来支撑查某个用户是否已经参团的重复校验。数据库连接池参数也做了调整。原来是初始连接10、最大连接50高峰明显不够用。我们把最大连接提升到200最小空闲连接保持在20避免频繁创建新连接。同时把获取连接的超时时间从默认值调低到3000ms——这样极端情况下拿不到连接的请求会快速失败并进入重试队列而不是无限等待把线程池拖垮。这里要提醒一句连接池参数不是随手拍的一定要以压测结果为依据。连接数开得太大MySQL本身也会吃不消因为每个连接背后都是一个线程、一块内存。我们最终定在200是反复压测后得出的平衡点。4. 第二板斧用Redis扛住第一波流量4.1 给库存加上缓存前置校验数据库层优化之后单次锁单操作已经非常快了但每秒几千个请求直接打到MySQL上依然不现实。我们的做法是引入Redis作为库存的前置卡口让绝大多数请求在Redis这一层就完成库存预校验只有真正有可能成功的请求才放行到数据库。这里必须强调Redis里的库存只是一个缓存副本数据库才是最终数据源。不能只改Redis里的数字就认为库存扣完了否则一旦Redis和数据库同步出错就会出现库存数据不一致。我们内部把它叫做前置卡口而不是独立库存含义就是它只负责挡流量不负责记真账。具体做法是活动开始前通过管理后台接口把活动库存预热到Redis用String类型存储key的格式是活动库存加活动ID。锁单请求进来时先用Lua脚本原子执行一次扣减校验if redis.call(GET, KEYS[1]) false then return -1 end local stock tonumber(redis.call(GET, KEYS[1])) if stock 0 then return 0 end redis.call(DECRBY, KEYS[1], 1) return 1脚本返回-1表示key不存在也就是还没预热或已失效返回0表示库存不足返回1表示扣减成功。只有返回1的请求才会继续走数据库的原子UPDATE。这样一来数据库实际承受的写并发就降下来了因为大多数请求在Redis层就被拦住。4.2 扣减成功的请求未必都能落库这里有个容易踩的坑Redis扣减成功了但数据库UPDATE失败了。比如数据库里的实际库存已经不足——因为Redis预热的数据量和数据库中的剩余量可能不完全一致又比如数据库UPDATE遇到死锁回滚导致Redis减了但数据库没减。我们的策略是补偿当数据库UPDATE影响行数为0或抛异常时要把Redis里刚才扣掉的库存加回来也就是对Redis key执行加1操作。这个补偿操作必须放在catch块里同时要在业务日志里记录补偿原因方便事后对账。如果补偿也失败了比如恰好赶上Redis宕机就让活动服务定时从数据库库存反推、修复Redis副本。这个补偿逻辑我们上线后跑了一阵子发现触发次数其实很少但绝不能因为没有频繁触发就不写。库存数据的绝对值一旦出错活动结束后的对账会让你痛不欲生。4.3 缓存穿透和热key的预防拼团活动天然就是热key场景所有用户进来都查同一个库存key。这个key是热点的原因很简单大家都在抢同一个活动的名额。但幸好操作很简单只有读取和减一单key吞吐量其实不低。我们的Redis采用集群模式把这个key放在一个分片上完全能扛下来前提是别在上面挂复杂的聚合读写。真正需要防的是缓存穿透如果某个key在Redis里不存在比如还没预热大量请求就会越过Redis直达数据库。我们在Lua脚本里返回-1的含义就是key不存在应用层看到-1不会放行到数据库而是直接返回活动未开始或维护中。同时管理后台预热库存的接口做了幂等控制避免多次初始化覆盖已有库存。为了不让Redis单点故障导致库存数据丢失我们采用的架构是缓存前置加数据库兜底Redis挂了也不会让系统完全不可用应用层降级到纯数据库模式走最原始的原子UPDATE路径。性能会下降但至少保证不超卖、不丢单。这个降级开关做在配置中心里可以秒级切换。5. 第三板斧异步削峰让锁单从快变稳5.1 同步锁单改异步消费数据库和缓存的优化能让单个请求变快但面对瞬间的流量洪峰单纯靠快还是不够因为一个请求即使只有10ms的数据库操作1万个请求依然需要1万次数据库往返。真正解决问题的思路是削峰把请求先收下来立即返回排队中真正的业务处理放到消息队列里慢慢消化。改造后的锁单流程变成了这样用户点击参团请求到达网关网关做基础校验包括登录态、频率、活动状态没问题后进入应用层应用层做幂等校验和Redis库存预扣然后往消息队列写入一条锁单消息返回给前端处理中消费端从队列取消息执行数据库原子扣减、插入拼团明细、创建订单前端轮询查询锁单状态或者通过推送拿到最终结果。这个模型的核心是快速响应加异步确认。锁单接口本身的响应时间从原来的780ms降到了50ms以内因为它只做了一件事把任务写进队列。真正的处理耗时不计算在用户的等待时间里了。5.2 队列消费的幂等与去重消息队列有一个绕不开的问题重复消费。我们的消息队列采用的是至少一次投递语义同一个锁单请求可能会被消费两次。如果消费端不做幂等处理就会出现同一个用户成功锁了两个名额。库存超卖还能靠SQL约束兜底但同一用户重复参团是业务逻辑错误必须从代码层面杜绝。幂等方案的核心是一个业务幂等键用户在某个活动下的唯一请求标识我用的是用户ID加活动ID加客户端请求ID拼接而成。消费端处理消息时先拿这个幂等键去Redis里执行SETNX写入一个标记只有第一次执行成功才继续处理后续逻辑。Redis的SETNX是原子操作天然适合做分布式幂等控制不需要再到数据库层加唯一索引。不过Redis SETNX也有过期时间的问题。我们给幂等标记设置了5分钟过期正常情况下消息处理秒级完成不会出问题。如果消息在队列里积压超过5分钟幂等标记就会失效可能导致重复处理。所以队列积压时间必须加监控当消息年龄超过1分钟就要触发告警提前干预。5.3 超时未支付订单的处理拼团锁单还有一个特点用户锁单后如果几分钟内没完成支付名额应该释放给后面排队的用户。最初我们让定时任务每分钟扫一次超时订单但全表扫描的效率太低高峰期还会跟正常请求抢数据库资源。改造方案是用延迟队列每条锁单消息都设置一个延迟时间比如15分钟未支付延迟消息就会自动进入超时处理队列。消费端收到后先检查订单状态如果仍未支付就执行释放名额、关闭订单。延迟队列配合定时任务兜底双保险防止漏处理。释放名额的操作同样要注意并发安全释放时先检查订单状态再用一条原子UPDATE把库存加回来最后把订单状态改成已关闭。整个过程必须保持幂等因为超时消息可能重复投递。我当时的做法是给释放操作加了一个释放标记字段只有第一次释放的请求会真正修改订单状态和库存后续重复请求直接返回。6. 限流熔断把未知风险挡在门外6.1 接口层限流用户维度和总量控制异步化之后系统的承载能力上了一个台阶但流量大到一定程度消息队列也会被撑爆。所以我们在接口层加了两层限流。第一层是用户维度限流每个用户在同一场活动中5秒内只允许发起一次锁单请求。这里用Redis的滑动窗口实现每个用户一个key过期时间5秒。这个key不是热点因为它是用户维度的分布非常分散。实际测试下来这套限流能把恶意刷接口的请求挡掉绝大部分。第二层是接口总量限流整个锁单接口的QPS上限设置为比正常流量稍高的值。这里用令牌桶算法实现放在网关层的过滤器里用Redis加Lua脚本做一个分布式令牌桶保证多实例部署下限流效果一致。为什么用令牌桶而不是固定窗口因为令牌桶允许一定程度的突发流量更适合营销活动场景——前几分钟流量集中爆发后面趋于平稳。6.2 熔断降级保护下游也保护自己拼团锁单链路依赖Redis和消息队列也依赖用户服务、商品服务等下游系统。如果Redis不可用降级策略是直接走纯数据库模式性能下降但系统不瘫。熔断针对的是下游服务的异常连续报错超过阈值就打开熔断开关锁单时不再实时查询用户信息而是使用缓存里的基础数据。这个降级方案并不是一锤子买卖。熔断器会在半开状态尝试放行少量请求做健康探测等服务恢复后自动关闭熔断。整个过程通过配置中心动态切换不需要发版。我们在演练时专门做过一次Redis宕机测试降级开关生效后接口响应时间从45ms涨到180ms但系统没有出现大面积报错订单数据也没有出问题。7. 压测实录优化效果到底怎么样7.1 压测方案和数据对比整个优化分三个阶段上线每个阶段结束都做了压测。压测工具用的开源压测工具压测脚本模拟用户真实行为先调活动查询接口再调锁单接口中间加随机思考时间。压测环境和生产环境配置基本一致数据库是同样的版本Redis和消息队列也都用真实集群。压测数据对比指标优化前数据库优化后缓存前置后异步化完成后平均响应时间780ms120ms80ms45msP99响应时间1.6s260ms180ms96msTPS21580022005200错误率8.5%0.8%0.1%0.02%这里有个细节值得说明异步化完成后的平均响应时间指的是接口受理时间——也就是写队列成功返回的时间。真正业务处理完成的时间分布在中位数1.2秒左右但用户看前端表现是点击后一两秒出结果这个体验其实比原来等待3秒以上要好得多。7.2 稳定性和容灾演练压测除了看数字还要看系统的稳定性。我们做了几个专项演练长时间高负载运行2小时观察有没有内存泄漏和连接泄漏模拟Redis宕机验证降级路径的响应和恢复模拟消息队列积压验证消费速率和告警机制模拟支付服务变慢验证熔断器能否及时打开。最值得说的是全链路演练。我们把压测流量和真实业务流量按比例混合先用10%的压测流量试水观察各项指标稳定后逐步增加到50%、100%。这个过程能发现不少单点压测发现不了的问题比如某个下游服务的连接池被打满或者日志写入磁盘IO过高拖慢了整个应用。8. 实战中踩过的坑和排查经验8.1 三个让我印象深刻的线上事故第一个坑是Redis预热数据和数据库真实库存不一致。活动开始后用户明显看到有库存但提交锁单时总提示失败大量用户投诉。排查后发现是预热任务在活动开始前5分钟执行但压测人员同时也在跑脚本消耗库存预热脚本覆盖了压测的扣减结果。修复方案是预热接口增加环境隔离压测环境不允许预热真实活动的库存key。第二个坑是消息队列积压导致超时释放失效。某次活动流量超出预期的两倍消息队列积压了很长时间等消费端处理锁单消息时用户已经在前端等得不耐烦关闭了页面。更麻烦的是积压期间幂等标记过期同一用户的消息被重复消费产生了几十条重复的拼团记录。修复方案是消费端增加了消息年龄校验超过3分钟的消息直接丢弃并记录日志同时把幂等标记的过期时间从5分钟延长到15分钟。第三个坑是数据库死锁。引入异步消费后多个消息同时处理同一个活动的库存偶发死锁。查看日志发现死锁发生在库存UPDATE和拼团记录插入之间——两个事务持有了对方需要的资源。解决方法是把库存UPDATE和拼团记录插入改成固定顺序并且让拼团记录插入走独立的短事务死锁基本消失。8.2 常见问题速查表现象可能原因排查手段接口响应慢数据库连接池耗尽、SQL未走索引、Redis热key查看连接池指标、慢查询日志、Redis监控库存扣减失败率异常高Redis预热数据过期或丢失、数据库死锁查看Lua脚本返回码、数据库死锁日志用户重复参团幂等标记失效、消息重复消费检查幂等键设计、消息去重日志超时订单未释放延迟队列消息丢失、释放消息被丢弃扫描超时记录、检查延迟队列配置活动开始瞬间流量打崩网关限流阈值设置不合理、网关性能不足压测网关单机吞吐、调整限流参数8.3 排查工具和思路如果你现在遇到类似问题我建议先看三样东西慢查询日志、连接池监控、GC日志。这三个能排除掉大部分常见问题。慢查询日志能直接告诉你哪些SQL在浪费时间连接池监控能暴露连接等待和泄露GC日志能看出是不是Full GC拖了后腿。如果问题出在Redis关注命中率和慢命令日志尤其是Lua脚本执行时间。如果问题出在消息队列关注积压数量和消费速率看消费逻辑有没有在等外部调用。我实际排查中发现过消费端调了外部接口对方超时5秒才返回导致消费速率断崖式下跌的情况。解决方案是把外部调用改成异步或者设置更短的超时时间加熔断保护。9. 几点个人体会优化做完后回头看真正让系统扛住流量的不是某一个奇技淫巧而是一整套组合拳数据库层用原子UPDATE解决并发安全Redis层拦住大部分无效流量消息队列把峰值压力削平限流熔断把未知风险隔离。每一步单独拿出来都不算难难的是判断在哪个环节用哪种手段以及知道什么时候该停。我的体会有两点最深刻。第一性能优化一定要用数据驱动不能凭感觉。我们一开始也纠结过要不要上分库分表、要不要引入更复杂的分布式事务中间件但压测数据显示根本不需要。过早引入复杂度只会让系统更难维护。第二异步化不是万能的。它把响应时间从780ms降到了45ms但也带来了幂等、补偿、状态一致性等一系列新问题。如果没有足够的监控和补偿机制异步化反而会让系统更脆弱。最后分享一个实用技巧上线前一定要留出完整的演练时间。我们把每个阶段优化的上线时间都安排在活动档期前两周压测、演练、复盘都做完才允许上生产。那次大促前一周的深夜我们做了最后一次全链路压测没有发现任何新问题我才有底气在群里说一句可以上。做技术优化这件事最怕的不是问题难而是问题藏在你看不见的地方。希望这篇复盘能帮你少踩几个坑。