一、抢购业务分析
1. 抢购业务的特性
(1) 低廉的价格
(2) 大幅推广
(3) 瞬间售空
(4) 定时上架，定时结束
(5) 并发量高
2. 技术挑战
(1) 对现有业务的冲击
(2) 高并发的环境下，数据库负担
(3) 高并发情况下网络的波动
(4) 前端对数据显示的处理
(5) 产品定时上架的处理
扫描二维码关注公众号，回复：
6516445 查看本文章
(6) 库存的“超卖”现象
(7) 秒杀器的应对
二、抢购业务架构原则
1. 尽量将请求拦截在系统上游
减轻后端数据层，数据读取的压力，防止服务器轻易挂掉
2. 读多写少，多使用缓存
减少数据库的读取次数
三、抢购业务架构设计
1. 整体架构
采用前后端分离的模式，后端只提供数据的操作，不负责前端页面的处理。采用RESTful API为前端提供数据，或者修改数据。前端采用react技术开发SPA单页应用，分离前后端，解耦系统，提高系统的稳定性和健壮性。采用nginx作为前端也后端交接的中转站，实现代理和负载均衡，减轻后台的请求静态资源，提高系统整体的稳定性。
2. 前端层架构
(1) 采用nginx和CDN做反向代理，快速响应来自于全国各地的请求，从而解决网络带宽的瓶颈。
(2) 倒计时的问题，由于客服端时间和服务器时间不一致，会导致抢购失败或者提前抢购。所以采用每隔一段时间，进行前后端时钟的同步。
(3) 当时间未到的时候，前端进行请求的拦截，采用节流的方式禁止前端在未开始时发送无效的请求。
3. 后端架构
(1) 在请购的API接口，实现一个抢购队列，放在“插队”行为。
(2) 采用mysql进行数据的存储，采用redis进行数据的缓存，在抢购开始的时，从mysql数据库中读取一次数据，把读取到的商品信息保存在redis缓存中，当每次执行抢购的时，从redis中读取商品信息，并修改相应库存，减轻mysql数据库的频繁读写。
(3) 在抢购成功过以后，如果用户在20分钟之内为付款则，商品重新进入抢购队列中进行抢购。
四、业务逻辑
- 流程图Step1：先经过Nginx负载均衡和分流
- 进入jseckill程序处理。 Google guava RateLimiter限流。 并发量大的时候，直接舍弃掉部分用户的请求
- Redis判断是否秒杀过。避免重复秒杀。如果没有秒杀过
把用户名（这里是手机号）和seckillId封装成一条消息发送到RabbitMQ，请求变成被顺序串行处理
立即返回状态“排队中”到客户端上，客户端上回显示“排队中...” - 后台监听RabbitMQ里消息，每次取一条消息，并解析后，请求Redis做库存减1操作（decr命令）
并手动ACK队列 如果减库存成功，则在Redis里记录下库存成功的用户手机号userPhone. - 流程图Step2：客户端排队成功后，定时请求后台查询是否秒杀成功，后面会去查询Redis是否秒杀成功
如果抢购成功，或者抢购失败则停止定时查询， 如果是排队中，则继续定时查询。
五、ER图
六、用例图
添加抢购商品流程：
前端抢购流程
后端处理数据流程
七、架构图
