电商系统在双11大促活动下的架构体系

tntxia
0 阅读7分钟

核心目标：高可用、高并发、高性能、数据一致性、可限流降级、可观测。

瞬间峰值流量（秒杀、开抢）、流量潮汐明显、读写严重不均衡、大量热点商品、支付链路资金敏感、库存不能超卖。

整体架构分层：接入层 → 网关层 → 业务应用层 → 中间件层 → 数据存储层 → 稳定性保障体系 → 大数据 & 运营体系，同时配套全链路压测、预案、降级熔断。

典型拆分：交易主链路（核心）、非交易链路（可降级）、离线链路，核心链路优先保障。

一、整体架构总图

image.png

二、各层详细设计（双 11 专项优化点）

1. CDN & 静态接入层

  • 静态资源：商品图、首页活动页、JS、CSS、静态活动页面全部下沉 CDN，回源限流；
  • 静态页面预渲染、预加载，大促页面提前缓存；
  • 防护：DDoS、CC 攻击防护，WAF 拦截恶意请求、爬虫、刷券、刷单。

2. 负载均衡 + API 网关层

作用：流量入口，第一道限流关卡 能力：

  1. 流量路由、灰度发布（按用户 / 区域切流量）；
  2. 全局限流：QPS 配额、账号维度限流、IP 限流；
  3. 鉴权验签、请求清洗、非法参数拦截；
  4. 协议转换（http/grpc）；
  5. 大促专属：多级限流桶，网关层直接拒绝超限流量，不往后透传。

策略：网关限流 > 应用层限流 > 业务层降级，尽早挡掉无效流量。

3. 微服务业务层（领域拆分，核心链路隔离）

✅ 核心链路（不能轻易降级）：商品 → 购物车 → 下单 → 扣库存 → 支付 ❌ 弱依赖链路（大促可以直接关掉）：评价、商品推荐、消息推送、积分、会员成长值

（1）商品 & 库存服务（最高风险，防超卖）

痛点：热点商品（爆款秒杀），流量集中打在少数 SKU 方案：

  • 库存分层：

    1. 总库存 DB；
    2. Redis 预热可售库存（预扣减）；
    3. 下单成功后异步同步 DB；

  • 分布式锁 + 库存 CAS，防止并发超卖；

  • 热点隔离：热点 SKU 分片、热点本地缓存、热点隔离集群，避免单点打爆；

  • 库存兜底校验：最终一致性校验，定时对账补偿；

  • 秒杀独立集群：秒杀和普通商品流量物理隔离，秒杀请求单独队列。

经典模型：预扣库存（Redis）→ 创建订单 → 支付超时自动回滚库存（延时消息）

（2）购物车服务

  • 购物车数据放 Redis；
  • 支持未登录、登录态购物车合并；
  • 大促可降级：购物车不实时计算优惠，下单时统一算；
  • 清理无效购物车、过期商品。

（3）订单服务（分库分表重点）

痛点：双 11 订单量爆炸，单库扛不住 方案：

  • 订单分库分表：按用户 ID 哈希 / 按时间分片；
  • 订单状态机严格：待支付 → 已支付 → 已发货 → 完成 / 关闭；
  • 超时关闭订单：延时 MQ，30min 未支付自动关单、释放库存；
  • 下单逻辑同步尽量短，非必要逻辑全部异步；
  • 防重复下单：幂等号（outTradeNo），每个请求唯一，保证幂等。

（4）营销服务（优惠券、满减、活动）

痛点：大量用户同时领券、抢券，容易出现超发券

  • 券库存放在 Redis；领券做原子扣减；
  • 券规则预计算、缓存；
  • 防刷：账号风控、设备风控、频次限制；
  • 降级开关：活动页面可关闭部分玩法（比如取消抽奖）保下单主链路。

（5）支付服务

资金链路，强一致性

  • 支付渠道聚合（微信、支付宝等）；
  • 支付回调幂等；
  • 本地事务表 + MQ 可靠消息实现最终一致性；
  • 支付结果异步通知，避免同步阻塞；
  • 对账系统：T+1 对账，以及实时异常账单巡检；
  • 支付限流：防止短时间大量支付打垮渠道。

4. 中间件层：削峰、缓存、解耦

  1. Redis（重中之重）

    • 集群模式 + 主从 + 哨兵；热点 key 拆分、避免大 key；
    • 多级缓存：浏览器缓存 → CDN → 本地 JVM 缓存（Caffeine）→ Redis；
    • 缓存预热：大促前提前把活动、商品、价格、库存刷入缓存；
    • 缓存穿透（布隆过滤器）、缓存击穿（互斥锁、永不过期热点）、缓存雪崩（随机过期时间）。

  2. 消息队列 MQ 核心思想：能异步全部异步，削峰填谷 异步场景：

    • 订单创建成功后：发消息通知物流、通知用户、统计报表；
    • 支付成功：积分、成长值、消息推送；
    • 超时关单、库存回补；
    • 日志、埋点、统计； 保障：消息持久化、重试机制、死信队列；消费集群水平扩容。

  3. 配置中心：动态下发降级开关、限流阈值，大促期间不用发版本。

5. 存储层

  • MySQL：核心交易数据，主从架构，读写分离；读流量走从库；订单表分库分表；
  • 限制：MySQL 不扛热点读，热点全部交给 Redis；
  • ES：商品搜索，搜索是弱链路，可降级（返回兜底静态商品列表）；
  • OLAP 引擎 ClickHouse：实时大屏、流量统计、订单大盘、风控指标。

三、稳定性体系（双 11 最核心的保障体系）

1. 限流、熔断、降级（三板斧）

  • 限流：网关限流、接口限流、单机限流、账号限流；区分普通流量和秒杀流量；

  • 熔断：下游服务异常（超时、报错率飙升），自动熔断，快速失败，避免雪崩；Sentinel 常用；

  • 降级：

    • 弱功能降级：关掉评价、推荐、签到；
    • 柔性降级：不实时计算优惠，展示近似价格；
    • 页面降级：活动页切静态兜底页；
    • 核心链路只保留：下单、扣库存、支付。

2. 全链路压测

  • 压测流量染色，压测数据隔离，不污染真实生产数据；
  • 模拟真实流量模型：潮汐流量、秒杀尖峰；
  • 压测目标：找到系统瓶颈，验证限流、降级、熔断是否生效；
  • 压测后扩容、调优参数。

3. 预案体系 + 红蓝对抗

  • 分级预案：一般告警、重大告警、极端峰值；
  • 故障演练 / 混沌工程：随机杀实例、断网络、打满 CPU，验证故障自愈；
  • 值班机制：大促期间多角色值班（开发、运维、DBA、风控）。

4. 可观测体系

  • 指标监控：QPS、RT、错误率、CPU、内存、连接数、缓存命中率、MQ 堆积；
  • 链路追踪：SkyWalking / Jaeger，追踪下单全链路耗时，快速定位慢节点；
  • 日志中心：ELK，异常日志告警；
  • 实时大盘：订单量、支付 GMV、库存消耗、报错看板。

5. 风控体系

  • 防刷券、防秒杀脚本、黄牛、恶意下单；
  • 账号风险、设备指纹、IP 风控；
  • 风控拦截流量，不进入业务链路。

四、交易流程

用户下单：

  1. 请求到网关，校验、限流；
  2. 查商品 Redis 缓存，校验活动、价格；
  3. Redis 预扣库存（原子操作）；
  4. 创建订单（DB 写入，状态待支付）；
  5. 返回收银台；
  6. 用户支付 → 支付渠道回调；
  7. 支付成功，更新订单状态；发送 MQ；
  8. MQ 异步触发：通知物流、发消息、统计；
  9. 延时消息：30 分钟未支付，关闭订单，库存回补。

五、重点注意

  1. 热点 key：爆款商品千万不要一个 Redis key 扛所有流量，做分片；
  2. 超卖：不要依赖 DB 悲观锁，性能扛不住；Redis 原子扣减 + 最终对账；
  3. MQ 堆积：消费能力提前扩容，堆积告警；
  4. 缓存雪崩：统一过期时间是大忌；
  5. 数据库压力：不要把所有查询打到 DB；
  6. 链路太长：同步链路越短越好，非核心全部异步；
  7. 降级顺序：优先砍非核心链路，最后才动下单支付链路。

六、架构演进方向

  • 单元化架构：多地域机房单元，每个单元独立闭环，就近流量调度，异地容灾；
  • 异地多活：一个机房挂了，流量切到其他机房；
  • 弹性扩缩容：基于流量自动扩容容器（K8s），大促前扩容、大促后释放资源。
avatar
文章
阅读
粉丝