毕业设计:设计电商秒杀系统
一、现状分析
技术团队 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、熔断设计
为了防止故障链式西效应,起到服务的自我保护
版权声明: 本文为 InfoQ 作者【Johnny】的原创文章。
原文链接:【http://xie.infoq.cn/article/f39faafff9c2d737f3460ee98】。未经作者许可,禁止转载。
评论