再见，秒杀

若有收获,请记得分享和转发哦

前言

最近心血来潮，想起前段时间公司举办的线下秒杀活动不理想，想研究一下秒杀系统的优化。当时活动现场有 200+ 会员，由于我们先前没有经验，各种原因导致用户在秒杀的时候 APP 页面白屏、卡死。业务部门想把手机甩我们开发脸上......当时我刚毕业也刚入职不久，不敢发表意见。现在逐渐膨胀，是时候重新设计一套秒杀系统了......

问题分析

有经验的同学看到 200+ 会员都出现白屏、卡死，可能会觉得公司技术太 low 。其实不然，公司系统架构还是很好的，大佬搭建了一套 SpringCloud 组件，都是比较新的版本。这次秒杀活动失利的确是之前没有这样的经验，很多代码考虑没到位，访问数据库的次数太多。虽然会员数是 200 ，但是会员从进入秒杀页面，点击秒杀商品，再到秒杀下单，这中间夸了几个微服务，对于数据库的访问远远不止 200 。

对代码分析之后，我们公司秒杀其实是和普通订单是同一个流程，只是加了一个秒杀 ID 字段。下单流程在一个事务里面各种校验、跨服务调用、加锁扣减库存、插入订单商品信息、物流配送信息......等。这样跨服务和多次访问数据库很明显无法满足秒杀业务瞬间流量巨大的特性。就像下面的图

秒杀流程

下面就是具体的秒杀流程详细图，按顺序描述每一节点要考虑的问题以及解决方案