业务场景：秒杀

系统简介

• 系统名：电商系统

• 主要功能：

  秒杀：公司策划了一场秒杀活动，该活动提供了100件特价商品（商品价格非常低），供用户于当年10月10日22点10分0秒开始秒杀。

• 业务分析：

  当时平台已经积累了几千万的用户量，预计数十万的用户对这些特价商品感兴趣。根据经验，特价商品一般会在1~2秒内被一抢而光，剩余时间涌进来的流量用户只能看到秒杀结束界面，因此预测秒杀开启那一瞬间会出现一个流量峰值。

• 限制条件：

  这是一场临时性的活动，领导要求别加太多服务器，也别花太多时间重构架构，也就是说需要以最小的技术代价来应对这次秒杀活动。

• 结果：

  这个秒杀项目上线以后，通过观察后台日志、内部监控平台的数据和第三方监控的数据，并用脚本对比库存扣减情况和订单情况，发现一切正常。因此，这次的秒杀架构是成功的。

失败经验

将秒杀的逻辑建构成了：必须保证前100名的客户可以抢到商品，并没有做限流等措施，因此后台服务器的压力很大，经常出问题。

虽然要保证前100名客户的订单成功，但是前面100名不一定就是第一时间点击秒杀按钮的客户，有些人网速快，有些人网速慢。另外，普通客户肯定没有专门“薅羊毛”的人操作快。对于普通客户来说，随机决定比单纯比快要更有机会下单成功。

后来，基本上秒杀架构都会设计限流。

有一些秒杀的代码是在前端的JS中随机抛弃掉一些请求，这其实也是某种意义上的限流，只不过不太合理，应尽量避免。