大家好，今天咱们来聊一个电商系统中最考验技术功底的模块——高并发优惠券系统。

为什么说它考验功底？想象一下：双11零点，100万用户同时抢10万张优惠券，既要保证不超发、不错发，又要让系统不崩溃，这背后的架构设计可大有讲究。

今天我就把这套从零到10万QPS的优惠券系统架构拆解给你看，保证通俗易懂，就算是刚入行的同学也能get到核心要点。

一、先搞懂：优惠券系统到底难在哪？

优惠券系统看似简单，实则藏着不少坑：

  • 并发量大：秒杀场景下，QPS可能从平时的100瞬间飙到10万+
  • 数据一致性：绝对不能超发，否则公司分分钟损失上百万
  • 业务复杂：要支持满减、折扣、限时、限量等N种规则
  • 性能要求高：用户抢券时，延迟超过1秒就可能骂娘卸载App

二、架构设计：分四层抗住10万QPS

1. 流量入口层：能挡多少是多少

CDN就像小区门口的快递柜，把静态资源（优惠券图片、规则说明）直接缓存到用户附近，不用每次都找服务器要。

Nginx是流量的「看门大爷」，可以做两件大事：

  • 限流：用limit_req模块把超过容量的请求直接拒绝，避免冲垮后端
  • 动静分离：静态资源走CDN，动态请求才到应用服务器
# Nginx限流配置示例
limit_req_zone $binary_remote_addr zone=coupon:10m rate=100000r/s;
server {location /api/coupon/seckill {limit_req zone=coupon burst=20000 nodelay;# 其他配置...}
}

2. 应用层：缓存+异步+服务拆分

Redis缓存是抗高并发的「黄金武器」：

  • 把优惠券信息、用户领取记录全放Redis里
  • 用Lua脚本原子性操作，防止超发
  • 热点数据预热，避免冷启动问题
// Redis Lua脚本防止超发示例
String luaScript = """
if redis.call('hexists', KEYS[1], ARGV[1]) == 1 thenreturn 0
elselocal stock = redis.call('get', KEYS[2])if stock and tonumber(stock) > 0 thenredis.call('decr', KEYS[2])redis.call('hset', KEYS[1], ARGV[1], 1)return 1elsereturn 0end
end
""";

异步处理：用RabbitMQ把非核心流程（比如日志记录、消息通知）异步化，减轻主流程压力。

服务拆分：把优惠券系统拆成领券、核券、券管理等微服务，各自独立扩容，互不影响。

3. 数据层：分库分表+读写分离

MySQL分库分表：

  • 按用户ID哈希分表，把数据分散到多个数据库
  • 大表拆小，提升查询和写入性能

读写分离：主库负责写操作，从库负责读操作，用MyCat或Sharding-JDBC做中间件。

4. 基础设施层：监控+告警+预案

  • 用Prometheus+Grafana监控QPS、响应时间、错误率
  • 设置告警阈值，一旦超过立即通知运维
  • 准备降级预案，流量太大时可以关闭部分非核心功能

三、核心技术点：解决优惠券系统的3大痛点

1. 防超发：Redis+MySQL双保险

  • 先用Redis做预扣减，保证并发下不超发
  • 异步同步到MySQL，最终一致性靠定时任务对账
  • 关键操作记录日志，方便回溯问题

2. 高性能券码生成：全局唯一ID生成器

  • 用雪花算法（Snowflake）生成全局唯一券码
  • 提前批量生成券码存入Redis，领券时直接分配
// 简化版雪花算法实现
public class SnowflakeIdGenerator {private final long workerId;private long sequence = 0L;private long lastTimestamp = -1L;public synchronized long nextId() {long timestamp = System.currentTimeMillis();if (timestamp < lastTimestamp) {throw new RuntimeException("Clock moved backwards");}if (timestamp == lastTimestamp) {sequence = (sequence + 1) & 4095;if (sequence == 0) {timestamp = tilNextMillis(lastTimestamp);}} else {sequence = 0L;}lastTimestamp = timestamp;return ((timestamp - 1288834974657L) << 22)| (workerId << 12)| sequence;}
}

3. 库存扣减：悲观锁？乐观锁？都不对！

  • 高并发下悲观锁会导致大量线程阻塞，性能差
  • 乐观锁用CAS操作，但并发太高会导致大量失败
  • 最优解是分段锁：把库存分成多段，每段独立加锁

四、架构演进：从小打小闹到10万QPS

  1. 初始阶段：单应用+单数据库，能满足日常1000QPS
  2. 成长阶段：加Redis缓存，分库分表，支撑1万QPS
  3. 成熟阶段：微服务拆分，异步化处理，支撑10万QPS
  4. 巅峰阶段：服务网格+容器化，自动扩缩容，应对双11流量

五、实战经验：这些坑你必须避开

  1. 不要过度设计：先满足当前需求，再考虑扩展
  2. 缓存不是银弹：缓存失效、穿透、雪崩等问题要提前预防
  3. 数据库是最后一道防线：索引优化、慢查询优化必须做
  4. 限流降级要狠心：该拒的请求要拒，该砍的功能要砍
  5. 压测是检验架构的唯一标准：上线前必须进行多轮压测

结语

搭建10万QPS的高并发优惠券系统，靠的不是某一项黑科技，而是架构分层、缓存优化、数据库调优、异步处理、限流降级等技术的综合运用。

记住：好的架构不是设计出来的，而是迭代出来的。从满足100QPS开始，逐步优化，最终你也能构建出支撑百万级流量的系统。

觉得有用的话，点赞、在看、转发三连走起！咱们下期见～