架构实战训练营毕业设计

一.需求背景

设计电商秒杀系统

【业务背景】

你作为一个电商创业公司的架构师，负责设计 6.18 大促秒杀系统的设计，你们的业务模式如下：

1.你们挑选选品各大电商平台上畅销和好评的商品进行销售，每个品类不超过 20 个商品，目前做了 10 个品类；

2.本次 6.18 秒杀选择了 1000 个充电宝，10 台 iPhone12 作为秒杀商品；

3.正常的日活大约 100 万用户；

4.老板要求万无一失。

【技术背景】

1.技术团队以 Java 为主，已经落地了微服务架构；

2.主要渠道是自有的 App（包括 iOS 和 Android）和微信小程序，为了促进用户转化为 App 用户，只有下载 App 才能参加秒杀活动；

3.目前只有单机房。

二.系统架构

由于系统已经落地了微服务架构,618 秒杀属于临时促销活动,所以将秒杀成功后下单支付等业务处理接入到系统已有的微服务中,在入口处复用商城原有的负载网关,增加秒杀微服务的复杂逻辑即可,增加秒杀限流网关,用于控制秒杀请求到达秒杀下单微服务的请求量,同时快速响应在限流策略判断秒杀失败时的请求.秒杀商品通产都是提前准备并在前端用户界面显示倒计时数量等信息,所以接入商品中心获取商品基本信息,秒杀商品信息微服务负责配置秒杀商品信息,处理前端查询秒杀商品信息的请求.

三.秒杀细节处理

1.商品秒杀规则配置及发布

秒杀商品都是从已有的品类中挑选的,首先请求商品中心获取商品信息,选择指定的商品并配置秒杀规则,规则保存至数据库指定表中同时加载至 redis 中,其中需要加载到秒杀商品列表中,用于前端 App 限制秒杀倒计时和数量等规则信息,还需要加载一份全部的商品秒杀配置,用秒杀商品的详情页展示.

2.秒杀商品下单

用户刷新秒杀商品列表并进入商品详情页,在秒杀未开始前限制倒计时秒杀数量等信息,秒杀开始后,用户可点击秒杀按钮,此时触发前端限制规则,如用户手机号最后一位与毫秒数最后一位相等等规则,如果不满足直接返回秒杀失败,由于商城日活一百万,秒杀商品数量只有一千台充电宝和二十台 iphone,所以秒杀失败后不可再次点击秒杀按钮,通过规则的用户进入负载网关,负载网关分发至秒杀限流网关,触发限流网关的限制规则,如是否在黑名单,当然参加秒杀的机会是否已达到上限等,未通过直接返回秒杀失败,通过的请求发送至秒杀微服务,秒杀微服务校验商品库存等信息,不满足返回秒杀失败,满足的请求发送至订单中心下单,并将订单信息返回,用户选择收货地址就可以下单并支付,秒杀处理完成.

四.高可用处理

负载网关和订单中心等其他商城服务保持原有的策略不变,秒杀服务使用原有的 redis 与数据库高可用策略即可,如果原有的 redis 策略是 sentinel,则为秒杀服务搭建 cluster 集群,数据库使用原有的复杂均衡策略.秒杀使用 nginx 搭建,在商城负载均衡网关中配置宕机后移除列表的配置,数据库维持原有的分片架构,每个节点主从复制即可.秒杀微服务等服务节点仅接收请求并处理,多个服务可以实现高可用,防止机房宕机造成用户体验差的问题,当 App 请求失败时,直接显示秒杀失败.由于只有单机房,所以秒杀服务无法单独实现异地多活的架构,需要与其他服务一起实现.

五.高性能处理

1.客户端限流策略

商城日活一百万,在高峰期参加秒杀活动的人大约有三十万,本次有一千个充电宝,需要在前端限制百分之九十的流量,策略设置为用户手机号末尾与系统毫秒时间末尾相同时,可以通过限制.

2.秒杀网关配置

使用 nginx+lua+redis 限制黑名单白名单用户,限流策略使用手机号对三取模等于 0 的请求通过,保证到秒杀处理微服务的请求与库存数量基本持平.

4.秒杀商品信息

秒杀商品信息配置后加载至缓存并主动发送通知至 App 端.

六.异常及灾备处理

1.异常处理

1.1 由于网络原因导致的请求失败,手机 app 端默认显示秒杀失败,并可进行重试.

1.2 秒杀成功的订单超时未支付,订单超时关闭后,秒杀活动可能已经结束了,所以不恢复名额,仅记入成功的数量.

1.3 秒杀成功但订单创建失败的,返回秒杀失败并恢复秒杀库存.

2.灾备处理

由于商城目前只有单机房,为保证万无一失,自建灾备机房时间可能不够,使用云厂商云服务搭建灾备集群,按照日活百分之三十的机器部署即可.