当前位置：首页 > news >正文

构建千万级用户的高并发抽奖系统架构

news 2026/5/11 22:35:27

1. 高并发抽奖系统的核心挑战

想象一下双11零点秒杀场景：数百万用户同时点击"立即抽奖"按钮，系统要在毫秒级完成库存检查、概率计算、结果返回等一系列操作。这不是简单的技术堆砌，而是一场对系统架构的极限考验。

我曾在某电商平台负责春节红包活动的技术保障，峰值QPS达到120万+。当时踩过的坑让我深刻理解到，高并发抽奖系统需要解决三个致命问题：

第一是库存超卖。当100个用户同时抽中最后一个iPhone时，系统必须保证只有1人真正中奖。我们采用Redis+Lua脚本实现的原子计数器，配合分布式锁双重保障，误差率控制在0.001%以内。

第二是概率失真。在流量洪峰下，简单的随机算法会导致热门奖品集中被前1%的用户抽走。后来我们引入时间因子和用户权重，确保活动全程的中奖分布符合预期。

第三是雪崩效应。某次活动因为奖品查询接口没有缓存，直接打垮数据库。现在我们的架构里，Redis作为第一道防线，本地缓存作为第二道，最后才是数据库。

2. 分布式锁的实战方案

2.1 为什么需要分布式锁

当用户A在华北节点检查库存时，用户B在华南节点也看到了同一个库存值。如果没有锁机制，两人都会认为自己抽中了最后一份奖品。这就是典型的并发写问题。

我对比过三种主流方案：

Zookeeper：强一致性最好，但性能只能到3000TPS
Redis：单节点5万TPS，但主从切换可能丢锁
ETCD：折中方案，2万TPS左右

最终选择Redisson实现的Redis锁，关键在这段配置：

RLock lock = redissonClient.getLock("lottery:"+activityId+":"+prizeId); // 等待3秒，持有10秒，避免死锁 boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS);

2.2 锁的粒度控制

早期我们把整个活动ID作为锁key，结果并发骤降到500TPS。后来拆分为"活动ID+奖品ID+用户ID分段"三级锁：

活动级锁：控制总参与人数
奖品级锁：控制单品库存
用户段锁：将用户ID哈希分片，避免热点

实测显示，这种分层锁设计能将并发能力提升8倍。比如某次活动，锁竞争从每秒15万次降到2万次。

3. 缓存策略的黄金组合

3.1 多级缓存架构

我们的缓存设计像洋葱一样分层：

本地缓存：Caffeine存储用户最近抽奖记录，命中率约40%
Redis集群：存储活动规则和实时库存，响应时间<2ms
数据库缓存：MySQL查询缓存配合读写分离

特别重要的是库存预热。活动开始前1小时，通过定时任务将数据加载到Redis：

def preheat_inventory(activity_id): prizes = get_prizes_from_db(activity_id) for prize in prizes: redis.set(f"stock:{prize.id}", prize.quantity) redis.expire(f"stock:{prize.id}", 86400) # 24小时过期

3.2 缓存更新策略

遇到过最棘手的缓存一致性问题：某用户中奖后，奖品已发但缓存未更新。现在的解决方案是：

先更新数据库
再删除缓存（不是更新）
通过消息队列异步重试

对于特别敏感的数据，比如剩余奖品数，我们采用Redis的WATCH+MULTI命令实现原子操作：

local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECR', KEYS[1]) return 1 end return 0

4. 异步化设计的艺术

4.1 消息队列选型

对比过Kafka和RabbitMQ的实测数据：

Kafka：吞吐量20万+/s，但延迟在50ms左右
RabbitMQ：吞吐量5万/s，延迟可控制在5ms内

最终选择RabbitMQ处理奖品发放，关键配置：

spring: rabbitmq: listener: simple: prefetch: 50 # 每个消费者最多预取50条 concurrency: 10 # 10个并发线程

4.2 事务消息方案

中奖记录要保证100%不丢失，我们实现了本地消息表：

将消息和业务数据放在同一个事务
后台任务扫描未发送消息
消息状态变更采用乐观锁

@Transactional public void saveRecordAndMessage(LotteryRecord record, Message message) { recordMapper.insert(record); message.setStatus(0); // 待发送 messageMapper.insert(message); }

5. 数据库的生存之道

5.1 分库分表策略

抽奖记录表采用"活动ID+用户ID后两位"分片。例如：

用户ID 123456 参加活动 888
分片键计算：888_56 → 路由到第56个分片

配合MyCat中间件，单表数据量始终控制在2000万以内。

5.2 索引优化实战

通过EXPLAIN分析发现，联合索引的顺序对性能影响巨大。最优方案是：

ALTER TABLE lottery_record ADD INDEX idx_activity_user (activity_id, user_id, create_time);

某次优化后，查询速度从1200ms降到28ms。关键是要让索引覆盖WHERE和ORDER BY子句。

6. 限流与熔断机制

6.1 分布式限流

采用令牌桶算法，通过Redis实现集群限流：

public boolean tryAcquire(String key, int permits, int rate) { String script = "local current = redis.call('get', KEYS[1])\n" + "if current and tonumber(current) >= tonumber(ARGV[1]) then\n" + " return 0\n" + "else\n" + " redis.call('incrby', KEYS[1], 1)\n" + " redis.call('expire', KEYS[1], ARGV[2])\n" + " return 1\n" + "end"; return redisTemplate.execute( new DefaultRedisScript<>(script, Boolean.class), Collections.singletonList(key), permits, rate); }

6.2 降级策略

当库存服务不可用时，自动切换本地缓存模式：

读取最后一次同步的库存快照
标记为"估算模式"
每隔30秒尝试恢复连接

7. 监控体系的搭建

7.1 指标埋点

通过Micrometer暴露关键指标：

lottery_requests_total：总请求量
lottery_duration_seconds：耗时分布
lottery_inventory：实时库存

Grafana看板配置示例：

SELECT rate(lottery_requests_total[1m]) as qps, histogram_quantile(0.95, sum(rate(lottery_duration_seconds_bucket[1m])) by (le)) as p95 FROM metrics WHERE activity_id='888'

7.2 全链路追踪

通过SkyWalking追踪一次抽奖请求：

API网关 → 抽奖服务 → 库存服务
每个环节的耗时和状态
异常请求的完整上下文

某次故障排查中，这个体系帮我们定位到是Redis连接池耗尽问题。

8. 安全防护体系

8.1 防刷策略

基于用户行为的防御矩阵：

设备指纹识别
请求频率分析（短时密集请求拦截）
中奖模式检测（如连续中高价值奖品）

def check_risk(user_id): if redis.get(f"block:{user_id}"): raise RiskException("用户被封禁") count = redis.incr(f"req:{user_id}") if count > 100: # 每分钟100次以上 redis.setex(f"block:{user_id}", 3600, "1") raise RiskException("请求过于频繁")