前言

本文作为架构设训练营毕业设计，重点讨论了电商秒杀系统架构设计，并没涉及其他部分系统如用户登录和库存管理的架构设计。

1. 业务背景

1.1 整体业务分解图

整体电商业务可以分解为以下服务，本文集中问题商品服务，尤其在秒杀场景下，系统架构设计。

2. 约束和限制

使用 Java

3. 总体架构设计

3.1 设计分析评估

3.1.1 高性能设计分析

3.1.2 高可用设计分析

3.1.3 可扩展设计分析

• 业务服务器可以横向扩展。在非秒杀期间，并不需要太多业务服务器。只有在秒杀期间才需要增加业务服务器

• 对于日活 100 万情况，我们只需要单机房，未来可扩展为同城双机房。现在双机房备灾，再作双活。双活可以看作单一逻辑机房，不用考虑数据一致性和通信延时。

• 未来日活增加后，可以做异地双机房。由于数据库使用主备架构，可以很容易把备机放在异地机房，成为异地互备。

3.1.4 成本分析

尽量使用开源软件（Redis，MySQL，HDFS），节省成本。业务日活增加后，可以改用其他商业软件。

3.2 总体架构设计

电商平台系统架构可按下图设计。单机房情况可以参照下图的单分区进行设计。

3.2.1 客户端设计

客户端支持自开发 APP 和微信小程序。

3.2.2 负载均衡架构设计

100 万日活使用 3 级负载均衡，即使在秒杀期间，Nginx 作为 1 级负载均衡也足够。未来扩展可以改用 F5/LVS 替换 Nginx，或者在 Nginx 上加上另一极负载均衡，成为 4 级负载均衡。

3.2.3 缓存架构设计

由于使用缓存，即使有大量用户浏览秒杀商品，如商品信息、商品类别、和库存数量等等，系统也可以及时处理。购买秒杀商品则使用队列记录用户购买信息。

4. 详细设计

4.1 核心功能

4.1.1 购买秒杀商品

4.2 关键设计

4.2.1 使用秒杀队列

基于 MySQL 建立秒杀商品队列，两个秒杀商品分别设立秒杀队列。

1. 充电宝购买秒杀队列 - 只保存前 1100 个充电宝购买请求，处理前 1000 个请求，其他请求直接返回秒杀结束。如果前 1000 个请求中有购买失败的，比如信用卡信息失效、或请求信息错误，可以从 1001 个请求开始到 1100 个请求中按优先顺序选作替补。

2. IPhone 12 购买秒杀队列 - 只保存前 20 个 IPhone 12 购买请求，并处理前 10 个请求，其他请求直接返回秒杀结束。后 10 个请求，在当前 10 个请求失败时作为替补。

业务服务器也有应用内队列（保存秒杀上限个请求），使用连接池与数据库连接（避免过多请求同时访问数据库）。业务服务器的应用内队列另一个好处是，即使 MySQL 服务器在秒杀期间故障了，业务服务器还保存着足够的秒杀请求来完成秒杀活动，等 MySQL 恢复了，业务服务器再把秒杀请求写入服务器。

秒杀请求被加入 MySQL 秒杀队列后并不马上处理，系统使用异步机制从队列中读出请求并处理，以减少延时、提高秒杀期间系统效率。

由于所有业务服务器均可以访问秒杀队列，不需要额外运算同步机制，使用 MySQL 的事务机制就可以处理多台购买服务器的同步写请求。加入购买信息前，仍先查看 MySQL 数据库队列请求数，只要超过运行秒杀上限，就返回秒杀结束；如果还没超过上限，则加入队列。

4.2.2 数据存储可用性

MySQL 数据使用主备模式，

4.3 设计规范

1. 支持 HTTPs

2. 使用 Restful 协议提供服务接口

3. 数据库支持 SQL 语言

5. 质量设计

5.1 成本

本设计主要在两方面节省成本

1. 使用开源软件

2. 业务系统可以横向扩展。在非秒杀期间，并不需要太多业务服务器。只有在秒杀期间才需要增加业务服务器。

5.2 可测试性

基于 HTTP 通信协议、使用 RESTful API 的微服务便于测试。

5.3 可维护性

做为基础服务架构，zookeeper 提供完整业务注册、发现、启动自动化的服务。

5.4 可观测性

开发系统时提供可观测接口。

1. 系统提供 logging 系统，便于观看运行流程

2. 系统提供后台监控进程，监控运行状态

6. 演进规划

当日活量提高到 1000 万量级，可以采用以下方法演进系统

• 负载均衡可以使用 F5/LVS

• 增加 Redis 集群数量

• 增加业务反向代理集群数量

• 数据库可以使用主从，或分片设计。