电商秒杀系统架构设计

前言

1. 业务背景

1.1 整体业务分解图

2. 约束和限制

3. 总体架构设计

3.1 设计分析评估

3.1.1 高性能设计分析

3.1.2 高可用设计分析

3.1.3 可扩展设计分析

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

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

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

3.1.4 成本分析

3.2 总体架构设计

3.2.1 客户端设计

3.2.2 负载均衡架构设计

3.2.3 缓存架构设计

4. 详细设计

4.1 核心功能

4.1.1 购买秒杀商品

4.2 关键设计

4.2.1 使用秒杀队列

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

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

4.2.2 数据存储可用性

4.3 设计规范

• 支持HTTPs

• 使用Restful协议提供服务接口

• 数据库支持SQL语言

5. 质量设计

5.1 成本

• 使用开源软件

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

5.2 可测试性

5.3 可维护性

5.4 可观测性

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

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

6. 演进规划

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

• 增加Redis集群数量

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

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