架构训练毕业设计+总结

设计电商秒杀系统

【业务背景】

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

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

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

• 正常的日活大约 100 万用户;

• 老板要求万无一失。

【技术背景】

• 技术团队以 Java 为主，已经落地了微服务架构;

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

• 目前只有单机房。

【毕设要求】

• 设计完整的架构，例如存储、负载均衡、缓存、高可用、可扩展等;

• 大约 10 页以内的 PPT，每页 PPT 说明一项设计，包括架构设计和设计理由，无需详细解释备选方案。

【提示】

• 分析考虑要全面，但并不意味着架构设计要面面俱到，如果分析后认为某些设计点可以不做，就在作业最后统一说明原因即可;

• 如果没有思路，请对照模块 9 的 IM 案例;

• 如果有的信息觉得不够全或者不够细，可以做出一定的假设，但不能天马行空，需要对照已有的业务背景和技术背景进行合理推断。

情景假设

• 日活百万：正常的日活已经达到 100 万

• 微服务：已经落地了微服务架构

• 单机房：目前只有单机房，目前秒杀活动不能冲击公司整体系统可用性

• 团队规模：“百万规模架构”，技术团队规模约 30 人

微服务划分和系统架构

总体架构思路

基于现有服务

主要复用以下几个服务：

• 用户微服务

• 账户微服务

• 交易微服务（支付）

做好隔离

• 只有单机房，不能对正常业务造成冲击，秒杀系统与现有系统隔离

• 采用流量倒漏斗，使得只有必要的流量进入现有服务

• 在漏斗入口增加各级缓存，保护漏斗底部的现有服务

存储架构

性能估算

• 用户量：日活 100 万，假设一半的用户参加秒杀，即用户量为 50 万

• 行为建模：假设秒杀活动在 0.5 秒内结束

• 数据量：主要是库存数据，数据量不大

• 1000 个充电宝

• 10 台 iPhone 12

• 读写性能

• 查询库存 QPS：50 万用户 / 0.5 秒 = 100 万

• 减库存 TPS：iPhone 12 在 0.1 秒内卖完： 10 / 0.1 = 100；充电宝在 0.5 秒内卖完：1000 / 0.5 = 2000

选择逻辑

存储架构图

查询库存和减库存

• 当仍然有库存时，执行 Lua 脚本，去 Redis 中减库存，并更新本地库存

• 再次（原子地）查询库存并减库存，返回最新库存

• 如果成功，去数据库真正减库存

• 减库存

• 更新本地库存

注：

• Redis 中查询库存和减库存作为一个原子操作，由 Lua 脚本实现；由于涉及到写操作，只能在主节点进行。同时又由于秒杀商品较少，无法采用 Redis cluster，所以采用 Redis sentinel。

• 由于 Redis sentinel 无法满足性能估算中的查询 QPS，所以引入进程内缓存支持库存查询。

• 由于“老板要求万无一失”，而 Redis sentinel 主从建数据不是严格一致，所以为了在 Redis sentinel 发生主从切换时不超卖，去数据库中真正的减库存。

计算架构

性能估算

与存储架构性能估算相同

负载均衡

• 由于目前只有一个单机房，所以没有 DNS 负载均衡；

• 由于是创业公司，使用 LVS 即可满足估算的性能需求；由于需要使用限流算法，LVS 下再增加 Nginx；

• 主要是估算业务服务器进程内缓存抗住查询 QPS，一般情况下按照每台服务器 1000 左右 的 TPS/QPS 来估算，需要 50 万/1000 = 500 台。由于业务服务器集群后主要接 Redis，只有很少量的请求需要写数据库，所以按照每台 2000 的 TPS/QPS 来估算，仍需要 50 万/2000 = 250 台；

• 服务器数据过于巨大，考虑成本，降低服务器数量，故此时必须引入限流、排队算法。

缓存架构

接口高可用

​ 编辑删除 

毕业总结

对架构设计有一个初步的认识，有一个大致的概念。任重而道远。