在线抢购系统需求分析报告

本文围绕抢购业务展开,分析其特性与技术挑战,提出架构原则。架构设计采用前后端分离模式,前端用react开发,nginx代理;后端用mysql存储、redis缓存。业务逻辑含限流、消息队列等处理,还给出ER图、用例图和架构图。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、抢购业务分析

1. 抢购业务的特性

(1) 低廉的价格

(2) 大幅推广

(3) 瞬间售空

(4) 定时上架,定时结束

(5) 并发量高

2. 技术挑战

(1) 对现有业务的冲击

(2) 高并发的环境下,数据库负担

(3) 高并发情况下网络的波动

(4) 前端对数据显示的处理

(5) 产品定时上架的处理

(6) 库存的“超卖”现象

(7) 秒杀器的应对

二、抢购业务架构原则

1. 尽量将请求拦截在系统上游

减轻后端数据层,数据读取的压力,防止服务器轻易挂掉

2. 读多写少,多使用缓存

减少数据库的读取次数

三、抢购业务架构设计

1. 整体架构

采用前后端分离的模式,后端只提供数据的操作,不负责前端页面的处理。采用RESTful API为前端提供数据,或者修改数据。前端采用react技术开发SPA单页应用,分离前后端,解耦系统,提高系统的稳定性和健壮性。采用nginx作为前端也后端交接的中转站,实现代理和负载均衡,减轻后台的请求静态资源,提高系统整体的稳定性。

2. 前端层架构

(1) 采用nginxCDN做反向代理,快速响应来自于全国各地的请求,从而解决网络带宽的瓶颈。

(2) 倒计时的问题,由于客服端时间和服务器时间不一致,会导致抢购失败或者提前抢购。所以采用每隔一段时间,进行前后端时钟的同步。

(3) 当时间未到的时候,前端进行请求的拦截,采用节流的方式禁止前端在未开始时发送无效的请求。

3. 后端架构

(1) 在请购的API接口,实现一个抢购队列,放在“插队”行为。

(2) 采用mysql进行数据的存储,采用redis进行数据的缓存,在抢购开始的时,从mysql数据库中读取一次数据,把读取到的商品信息保存在redis缓存中,当每次执行抢购的时,从redis中读取商品信息,并修改相应库存,减轻mysql数据库的频繁读写。

(3) 在抢购成功过以后,如果用户在20分钟之内为付款则,商品重新进入抢购队列中进行抢购。

四、业务逻辑

 

  1. 流程图Step1:先经过Nginx负载均衡和分流
  2. 进入jseckill程序处理。 Google guava RateLimiter限流。 并发量大的时候,直接舍弃掉部分用户的请求
  3. Redis判断是否秒杀过。避免重复秒杀。如果没有秒杀过 
    把用户名(这里是手机号)和seckillId封装成一条消息发送到RabbitMQ,请求变成被顺序串行处理 
    立即返回状态排队中到客户端上,客户端上回显示排队中...”
  4. 后台监听RabbitMQ里消息,每次取一条消息,并解析后,请求Redis做库存减1操作(decr命令) 
    并手动ACK队列 如果减库存成功,则在Redis里记录下库存成功的用户手机号userPhone.
  5. 流程图Step2:客户端排队成功后,定时请求后台查询是否秒杀成功,后面会去查询Redis是否秒杀成功
    如果抢购成功,或者抢购失败则停止定时查询, 如果是排队中,则继续定时查询。

 

五、ER

 

 

六、用例图

添加抢购商品流程:

 

 

前端抢购流程

 

 

后端处理数据流程

 

 

七、架构图

 

 

转载于:https://www.cnblogs.com/pawn2018/p/10822785.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值