整体思路：秒杀系统的整体设计思路

场景：如何设计一个秒杀系统？

前两节我们了解了秒杀业务的独特特点和技术挑战。现在让我们站在更高的角度，从宏观层面设计秒杀系统的整体架构。

设计目标：

输入：
- 秒杀QPS：50万
- 库存：100件
- 持续时间：3秒
- 用户：50万人参与

输出：
- 系统架构图
- 核心技术选型
- 关键设计决策

整体架构设计

三层架构概览

秒杀系统采用分层架构，每一层解决特定问题：

┌─────────────────────────────────────────┐
│          用户层 (Client Layer)          │
│  • 浏览器/APP                           │
│  • 静态资源 CDN                         │
│  • 本地缓存                             │
└─────────────────────────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│         网关层 (Gateway Layer)           │
│  • 负载均衡                             │
│  • 限流熔断                             │
│  • 防刷风控                             │
└─────────────────────────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│         服务层 (Service Layer)          │
│  • 秒杀服务                             │
│  • 库存服务                             │
│  • 订单服务                             │
└─────────────────────────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│         数据层 (Data Layer)              │
│  • Redis (库存缓存)                     │
│  • MQ (消息队列)                        │
│  • MySQL (持久化)                       │
└─────────────────────────────────────────┘

各层职责详解

核心设计思路

思路一：流量削峰 🏔️

核心理念：不要让流量洪峰直接打到数据库

思路二：缓存优先 ⚡

核心理念：能走缓存就走缓存，别打数据库

思路三：异步处理 📨

核心理念：快速响应，异步处理，别让用户等

思路四：可降级 ⬇️

核心理念：系统压力过大时，优雅降级，保核心功能

核心技术选型

数据层选型

系统架构图

关键设计原则

想一想

在继续学习之前，请思考以下问题：

问题 1：为什么要把库存放在Redis？

为什么不能用数据库直接扣库存？

提示：

• Redis是内存操作，速度快
• Redis单线程，无锁竞争
• Redis支持原子操作

问题 2：为什么要用消息队列？

为什么不能直接下单？

提示：

• 削峰填谷
• 异步处理
• 解耦

问题 3：如何保证Redis和MySQL数据一致？

Redis扣减了库存，MySQL还没同步，怎么办？

提示：

• 最终一致性
• 对账机制
• 补偿机制