比特麒麟

https://github.com/bitkylin

0%

亲自动手设计一个高并发的秒杀系统

设计一个高并发的秒杀系统,并产出架构图、设计文档等。

一、需求

  1. 有多款商品,每款商品均100件,每人限每款商品最多购买一件。
  2. 在X月X日 X时X分0秒开启购买。在约定时间之前,只能看到产品页面,购买按钮置灰。

二、活动预估

  1. 预计每种商品数万人参与
  2. 活动开始后半分钟内,预计每种商品收到10W次交易请求,预计总TPS:20W/s
  3. 活动开始半分钟后,预计绝大多数商品已售罄,剩下的商品仍支持秒杀,预计总TPS:2000/s

三、系统现状

  1. 系统可保持长期稳定运行的最大TPS:1000/s
  2. 短时间「1分钟内」系统未拒绝服务的最高TPS:1500/s

四、设计预研

方案一:改造现有系统,微服务系统整体大幅增加TPS

优点:

  1. 大幅增加TPS后,业务系统可直接承载巨量交易请求,应付秒杀需求会更加从容。

缺点:

  1. 秒杀活动次数少,改造成本、风险较大,性价比低
  2. 改造后,系统架构会更加复杂,可维护性降低

方案二:开发新应用,承载该需求;改造现有应用以支持新应用

优点:

  1. 对现有业务系统改造小,成本低。
  2. 使用新应用承载秒杀交易请求,灵活度高,不用过多考虑向后兼容问题。

缺点:

  1. 需要一定程度牺牲用户体验。

结论

基于成本和可行性考虑,采用方案二

五、架构设计

5.1 现有架构设计

  1. 前台应用直接承接用户访问、交易请求,无CDN服务。
  2. 前台应用接收到交易请求后,直接RPC同步请求中台应用
  3. 中台应用受到交易请求后,同步完成创建订单、支付、扣减商品数、完成交易等业务流程
  4. 前台应用接收到中台应用的处理结果,向用户展示交易商品的物流信息。

5.2 最新架构设计

5.2.1 架构设计一览图

5.2.2服务模块设计

1. 前端、客户端随机丢弃交易请求
  1. 根据用户查看商品详情页的次数,预估商品的热门程度,对不同商品设定不同的丢弃比率,设计字段:discard,取值为 [0, 100),作为商品属性。
  2. 前端、客户端,在用户提交交易请求时,生成 [0, 100] 范围内的随机数,discard < 随机数的订单直接丢弃,但向用户展示排队页面,排队10秒后直接显示交易失败。
2. 提供CDN服务
  1. 静态资源均保存在CDN服务中
  2. 前端展示的专门秒杀页面,除了「交易发起」请求外,用户的任何操作均不会请求到公司的微服务业务系统。
3. 开发专门的「秒杀应用」,提供熔断服务
  1. 秒杀应用直接承载前端、客户端的交易请求,授权通过的请求发往前台应用处理,授权拒绝的请求直接拦截,返回交易失败。
  2. 秒杀应用通过配置中心,实时获取最新配置。可配置对交易的丢弃比率,开发同事在秒杀时间段内,调整配置,保证发往业务系统的交易请求,TPS保持在 10000/s 以内。
  3. 秒杀应用无数据库,无状态,水平扩展后可成比例增加吞吐量。
4. 现有业务系统优化吞吐
  1. 前台、中台各应用,通过优化设计进而优化吞吐,有如下优化方式:
    • 采用分库分表等水平拆分方式,横向扩展数据库,此时也可以大幅增加POD数了
    • 静态数据缓存在Redis中,数据从Redis中取,保证不会读取数据库,后台定时任务更新缓存。「保证缓存定时更新且无缓存击穿」
  2. 分库分表策略:
    • 按照商品拆分数据库与应用
    • 按照用户id二次拆分数据库与应用
  3. 经过上述优化,至少可以将中台业务系统的短时间「1分钟内」系统未拒绝服务的最高TPS,由2000/s提升至4000/s
  4. 由于前台应用逻辑较简单,TPS可提升至10000/s,无需再优化。
  5. 由于木桶效应,业务系统整体的短时间「1分钟内」系统未拒绝服务的最高TPS,为4000/s
5. 异步队列
  1. 前台应用效率较高,此处仅优化中台应用即可。
  2. 前台应用将秒杀交易请求均发往 Kafka,中台应用通过 Kafka 消费消息,进行实际业务处理。
  3. 由于业务高峰时间段最多仅有半分钟 ~ 1分钟,中台应用在 2 分钟左右处理完全部交易也可以接受。
  4. Kafka 的 TPS 为数十 W/s,承载前台 5000/s ~ 10000/s 的TPS毫无压力。
  5. 经此优化,业务系统整体的短时间「1分钟内」系统未拒绝服务的最高TPS,可从 4000/s 提升至 10000/s

缺点:极端情况下,交易处理会较为缓慢。

6. 服务降级
  1. 秒杀开始前半小时到秒杀结束后的半小时,这个时间段内,部分服务降级
  2. 时间段内,不展示物流信息、不支持生成及展示发票,保证核心业务系统的稳定