44 | 记一次双十一抢购性能瓶颈调优

刘超



该思维导图由 AI 生成，仅供参考

你好，我是刘超。今天我们来聊聊双十一的那些事儿，由于场景比较复杂，这一讲的出发点主要是盘点各个业务中高频出现的性能瓶颈，给出相应的优化方案，但优化方案并没有一一展开，深度讲解其具体实现。你可以结合自己在这个专栏的所学和日常积累，有针对性地在留言区提问，我会一一解答。下面切入正题。
每年的双十一都是很多研发部门最头痛的节日，由于这个节日比较特殊，公司一般都会准备大量的抢购活动，相应的瞬时高并发请求对系统来说是个不小的考验。
还记得我们公司商城第一次做双十一抢购活动，优惠力度特别大，购买量也很大，提交订单的接口 TPS 一度达到了 10W。在首波抢购时，后台服务监控就已经显示服务器的各项指标都超过了 70%，CPU 更是一直处于 400%（4 核 CPU），数据库磁盘 I/O 一直处于 100% 状态。由于瞬时写入日志量非常大，导致我们的后台服务监控在短时间内，无法实时获取到最新的请求监控数据，此时后台开始出现一系列的异常报警。
更严重的系统问题是出现在第二波的抢购活动中，由于第一波抢购时我们发现后台服务的压力比较大，于是就横向扩容了服务，但却没能缓解服务的压力，反而在第二波抢购中，我们的系统很快就出现了宕机。
这次活动暴露出来的问题很多。首先，由于没有限流，超过预期的请求量导致了系统卡顿；其次，我们是基于 Redis 实现了一个分布式锁分发抢购名额的功能，但这个功能抛出了大量异常；再次，就是我们误判了横向扩容服务可以起到的作用，其实第一波抢购的性能瓶颈是在数据库，横向扩容服务反而又增加了数据库的压力，起到了反作用；最后，就是在服务挂掉的情况下，丢失了异步处理的业务请求。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文详细分析了双十一抢购活动中的性能瓶颈及调优方案。首先介绍了抢购业务流程，包括用户登录、抢购倒计时、获取购买资格、提交订单和支付回调等环节。针对性能瓶颈进行了分析，包括商品详情页面、抢购倒计时、获取购买资格、提交订单和支付回调等环节可能出现的性能问题。最后，提出了针对性能瓶颈的调优方案，包括限流实现优化、流量削峰、数据丢失问题的解决方案等。文章通过具体案例和详细分析，为读者提供了抢购业务性能优化的实用指南。文章重点强调了减少抢购中操作数据库的次数、缩短抢购流程、分库分表优化订单表等核心优化点，并提出了限流、流量削峰等方式来保证系统稳定性。同时，还提出了解决数据丢失问题的重试机制。整体而言，本文为读者提供了在高并发场景下优化抢购系统性能的实用建议。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Java 性能调优实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(33)

最新
精选

zk_207
超哥，你们订单超时是基于定时任务去做的吗？比如我订单是3min有效，怎么保证3min没支付就取消？
作者回复: 我们是放在mq中去实现的，rabbitmq中有一个延时队列，当过期时间到了，就会被放到死信队列中，只要去死信队列中实时消费就好了。定时任务也是一种实现方式，在分布式部署定时任务时，要实现分布式定时任务。
2019-10-27
4
16
-W.LI-
课后思考题: 文中老师讲了预扣库存可以多放开一点。比如实际只有100件商品，允许预扣300。支付成功后扣去真实库存。之前某包买东西，就遇见过了几天客服联系说没货了退款这种。我之前做过一个是支付完真实库存扣件失败，直接退款回滚数据的。恶意用户刷单的话可以对用户进行封号处理，在redis中缓存用户待带支付的订单数，每次进入带支付前校验下待支付的集合里有多少(金额数目都可)。判定为恶意刷单的直接黑名单。某东用的好像是黑名单。
作者回复: 不是预扣库存多放开，是在预扣库存前设置一个购买资格，购买资格是300，预扣库存还是100不变。不会出现商品超卖的问题。问答题回答思路很好。
2019-08-31
3
12
阿卧
扣件库存用分布式锁，性能瓶颈就在分布式锁上。那么如何优化提高下单的qps呢？
作者回复: 使用更优的分布式锁，以及细化锁粒度，例如将一个库存分为多个库存等
2020-03-16
2
7
王三好
队列使用什么实现的
作者回复: 有界队列LinkedBlockingQueue或者Disruptor实现队列
2019-11-18

7
超威丶
没有比较好的办法，如果等到付款才扣减库存，可能会出现超卖！一般好的办法限制一个账户买同个商品的数量，减少损失
作者回复: 没有直接的解决方案，但是我们可以通过间接的方案来减少这种恶意锁单的问题。建立信用以及黑名单机制，首先在获取购买资格时将黑名单用户过滤掉，其次在获取购买资格后，信用级别高的用户优先获取到库存。用户一旦恶意锁单就会被加入到黑名单。
2019-08-31
2
7
zk_207
您好，请问本文中说的订单幂等性校验如何控制吗？还有就是库存放在缓存中，DB和缓存如何保证一致性？能说下解决方案吗？
作者回复: 通过分布式锁来控制的，在下单时，以缓存中的库存为准，不会修改DB中的库存，只有在支付完成之后，回调时去数据库中扣除库存，严格上来说，只要业务操作没有bug，两者的库存就是一致的
2019-10-24

6
zk_207
超哥，请教个问题，就是秒杀的时候我们一般是下单预扣减库存，比如10分钟之后如果没有支付的话库存回流，这时候怎么保证库存准确性与系统性能呢？
作者回复: 我们是通过一个生产者消费者的方式实现缓存库存的添加和删除，并且通过分布式锁来保证原子性
2019-10-25

4
钱
课后思考及问题 1：在提交了订单之后会进入到支付阶段，此时系统是冻结了库存的，一般我们会给用户一定的等待时间，这样就很容易出现一些用户恶意锁库存，导致抢到商品的用户没办法去支付购买该商品。首先，感觉老师的问题有点奇怪，没明白“某些用户恶意锁库存，导致抢到商品的用户没办法去支付购买该商品的”——我的理解，300个人抢到了抢购的商品，实际只有100个，如果是先款订单，谁先付款谁就先实际抢购到对应的商品呗！如果担心付款后，不要了要求退货，这就是另外的事情了，一般而言待抢购的商品都是物超所值的，需要担心的应该是多抢。如果是要控制有购买资格的人数，可以利用大数据用户画像的方式，将级别高信用好的用户优先放过去，当然，黑名单也用起来过滤掉恶意用户，再者就是限制用户购买的商品数量。
作者回复: 是的
2019-09-12

3
拒绝
我们可以考虑在分布式锁前面新增一个等待队列，减缓抢购出现的集中式请求，相当于一个流量削峰。当请求的 key 值放入到队列中，请求线程进入阻塞状态，当线程从队列中获取到请求线程的 key 值时，就会唤醒请求线程获取购买资格。老师这里不太理解！
作者回复: 相当于线程池中的阻塞队列
2019-09-04
2
2
梁中华
我们上次把redis客户端从jedis改成redission后，会有部分查询请求出现延迟几十毫秒的现象，换回jedis里面好了，不知道老师有没有遇到过这种情况，是不是netty的很么参数设置的不对？
作者回复: 是的，可以参考下官方的使用文档，在单机且运用服务的CPU核数比较小的环境下，可能测试性能效果没有很大差别，如果想要效果更明显，可以在redis集群环境且应用服务的CPU核数在16以上的环境下进行性能压测，效果会更明显。 https://github.com/redisson/redisson/wiki/2.-配置方法#21-程序化配置方法
2019-09-03

2

收起评论