写点什么

毕业设计:设计电商秒杀系统

用户头像
Johnny
关注
发布于: 2 小时前

一、现状分析


  • 技术团队 Java 技术为主、已落地微服务、目前单机房

  • APP 用户才能参与秒杀

  • 在销售商品<=10 个品类*20 个商品

  • 本次秒杀 2 个商品(1000 个充电宝、10 台 iphone12)

  • 正常日活大约 100w 用户

  • 目前只有单机房

  • 老板需要万无一失


二、业务分析


本次秒杀 2 个商品(1000 个充电宝、10 台 iphone12), 产生的秒杀订单 1000+10 = 1010 个。

日活百万,估计参与秒杀可能是平时流量的 1.5~2 倍。

老板需要万无一失。需要做好核心流程的梳理,保证核心流程的可用性。

三、设计的思路


  • 做好隔离。包括秒杀服务的隔离、中间件的隔离。单独部署服务集群,防止拖垮其他服务。

  • 多层限流。保证到达 DB 层能再可控的流量。

  • 尽量缓存。把商品提前预热到缓存,包括库存的数据。

  • 高可用设计。包括限流、排队、降级、熔断。

四、总体架构设计



五、存储架构设计



数据量不大,因为才秒杀 2 个商品(1000 个充电宝、10 台 iphone12),产生的秒杀数据才一千多条。

Mysql 做个主备即可。



Redis 主要做缓存,查询秒杀的商品信息


六、计算架构设计


6.1、负载均衡设计



因为系统日活有 100w,秒杀时候假设是平时的 1.5 倍~2 倍。LVS 可以抗住几十 w 的并发,通过前端加合法性验证(比如验证码,防机器人),到达 LVS 可以抵挡全部合法流量。


6.2、缓存设计



七、高可用设计


为了保证接口的高可用,大致思路分:1、限流+排队 2、熔断+降级


7.1、限流设计


用户请求的各个环节都可以限流:

  • 1、请求端的限流:发起请求的时候限流,被限流的请求实际上没有到后端服务器

  • 2、接入端的限流:接到业务请求的时候进行限流,避免请求进到实际的业务处理流程

  • 3、单个服务自我保护,如果请求太多,可以舍弃新的请求


7.2、排队设计



各个角色说明:

  • 1、排队模块。使用 Kafka 消息队列,将请求以先进先出的方式保存下来,队列大小可以比秒杀商品多一些。

  • 2、调度模块。根据秒杀服务处理能力检测,有能力处理,将队列的消息下方到秒杀服务中去。

  • 3、其他服务。真正的业务处理模块,如下单、完成交易。


7.3、降级设计



降级服务主要为了优先保证核心业务正常,比如这边保证秒杀的下单交易服务正常。其他服务视情况降级。


7.4、熔断设计


为了防止故障链式西效应,起到服务的自我保护


发布于: 2 小时前阅读数: 7
用户头像

Johnny

关注

种一棵树最好的时间是十年前,其次是现在。 2018.05.05 加入

关注微服务、架构等

评论

发布
暂无评论
毕业设计:设计电商秒杀系统