需求分析

• 在公司自研新零售SaaS产品的基础上，推出一款秒杀活动来丰富现有产品功能。老板的要求就一个，快。初创型公司拼的就是时间。时间紧，任务重，我的思路就是以极简方式先上线，后续进行迭代优化。同时先上线的好处也有很多，其中最大的好处就是可以更快接受市场的考验，得到用户的反馈，通过在反馈中不断重新校准与拥抱变化来打磨产品功能，也达到了敏捷开发的目的。

  应用场景

• 大量用户在同一时间抢购一件或多件商品，专业术语叫高并发。比如双十一日0点，iphone13在天猫旗舰店以5折限量销售100台，有1000w用户预约抢购，0点准时开抢。

  业务特点

• 大量用户在同一时间点进行抢购，服务器瞬时流量激增。

• 访问量远大于库存量，只有固定数量的用户能够秒杀成功。

• 业务流程相对简单，只需要下单操作。

  用户规模

• 1w以下，单体应用架构。

• 1w以上，分布式架构，实际集群数量可根据预估用户量来动态伸缩。

  功能设计

  因为是在公司自有产品功能基础上进行横向扩展，所以必须要结合当前产品功能特性进行规划与设计。

  整理思路：

  • 秒杀活动目前只投放到微信小程序端，CDN就省了，只对热点数据进行缓存即可，平台已集成Redis，延用即可。
  • 秒杀活动是基于商品模块的上游功能，系统已存在商品模块，必须基于现有商品模块，才能达到扩展到目的。
  • 秒杀活动可能存在稀缺性商品，可能会遭到DDoS攻击，需要高防IP，可以考虑阿里云DDoS防护。
  • 秒杀活动瞬时流量巨大，可能会导致服务器故障，需要分流，平台现使用 Nginx + Spring Cloud Gateway 做网关路由层，延用即可。

  • 秒杀活动商品售卖数量固定，为防止超卖发生，需要分布式锁，平台已集成Redis，延用即可。

    现已实现方案：

  • 通过分布式锁的方式控制”超卖“发生，能够进入到下单环节的订单，通过消息中间件异步处理。这种最简单的方案能够实现老板的”快“，流程简单，上线周期短。

    规划补充方案：

  • 兼容：目前只有微信小程序端，考虑到后续会上线H5端和Web端，CDN还是要提上日程的。

  • 网络：目前只针对本地用户或本省用户开放秒杀活动，后续要向全国推广，需要考虑多线路BGP服务器。
  • 缓存：最大程度静态化秒杀活动页面，将页面使用的数据查询接口，全部作为热点数据放入Redis中。
  • 分布式锁：增加分布式锁的失效机制，防止死锁发生。
  • 限流：网关入口使用Guava令牌桶算法；服务入口增加活动开始判断、重复秒杀判断；调用服务限流和熔断使用Sentinel。
  • 削峰：异步处理，将符合条件的订单发送到中间件消息队列中，在消费端处理订单时判断库存是否充足。
  • 服务：提升服务横向扩展的能力，适应不断变化的流量。

    扩展思考

• 这里还有一个问题，这个问题也是面试时面试官最喜欢问的：如何让秒杀、活动倒计时准确无误？当然，想做到准确无误是不可能的，因为每个单体客户端的网络状况和机器性能不可能完全相同，所以最多只能做到99%，相信随着科技的发展，未来一定会做到100%。我在GitHub上找到了一个解决方案，我个人认为这是目前我看过的最合理的解决方案。