返回项目

PROJECT FILE 03 · HIGH CONCURRENCY

大营销抽奖平台

抽奖只是用户看到的一次点击,系统真正承担的是峰值流量、有限库存与重复请求同时到来时的确定性。

Backend Architecture2024SHIPPED

项目背景

营销活动的流量具有明显峰值,而奖品库存、中奖概率和活动规则又必须保持可解释。平台需要把活动编排与底层可靠性能力分开,让业务可以快速配置活动,同时让库存、幂等和补偿继续由稳定的工程机制负责。

关键工程问题

  • 同一个请求被重试时,不能产生第二次参与或兑奖结果。
  • 高并发下库存扣减必须守住原子性,不能把超卖留给事后对账。
  • 消息链路出现超时或部分失败时,需要有可重放的补偿路径。
  • 活动规则频繁变化,但核心一致性约束不能随配置一起漂移。

从经验到可触摸的模型

下面的实验室不是线上系统复刻,而是把几个关键变量压缩成一个确定性模型。调整流量、中奖率、库存和系统防线,可以观察不同约束对结果的影响。

SYSTEM PLAYGROUND · 02

大营销抽奖压力实验室

调整流量、概率与防线,观察一次 60 秒峰值窗口会发生什么。

deterministic model v1.4
场景参数与结果同步
72,000 / min
1.25%
680
系统防线

已载入基准场景,调整参数后运行。

SIMULATION OUTPUT

峰值窗口 / 60s

SAFE TO CANARY
有效请求89,888输入 97,200
奖品发放680期望命中 1,124
规则拦截7,312重复请求 1,166
P95 延迟134 ms峰值 2,300 RPS
请求压力曲线8 × 7.5s sample
库存余量
0
超卖数量
0
事务成功率
99.96%

结果由固定峰值曲线与确定性规则计算;相同参数始终得到相同结果。

留下来的判断

高并发营销系统最重要的不是某一种中间件,而是把“不允许发生什么”实现成可以被测试和观察的系统不变量。技术选型会变化,这些约束应该继续留在架构里。