电商秒杀系统
京东大佬问我，要做一个电商秒杀系统，你需要如何进行架构呢？考虑哪些方面呢？核心代码与分析逻辑都写出来
核心关键点：电商秒杀系统 架构 核心代码，逻辑
首先，我回想一下秒杀系统的常见问题和解决方案。秒杀系统最大的挑战应该是高并发和防止超卖，对吧？然后还有系统稳定性、限流、缓存、数据库优化这些方面。
首先，用户可能是一个正在准备面试的开发者，或者是在实际工作中遇到这个问题。他们可能希望得到一个全面的架构设计，包括各个层面的考虑，比如前端、后端、数据库、缓存、分布式系统等。同时，核心代码可能指的是如何处理秒杀请求，比如使用Redis预减库存，异步下单等。
接下来，用户可能没有明确说出的一些需求，比如系统的可扩展性、容错机制、如何应对突发流量，以及安全性问题，比如防止机器人抢购。所以，在设计架构的时候，需要考虑这些隐性的需求。
然后，我需要分步骤来思考。首先，前端部分如何做，比如静态化页面、按钮防重复点击、CDN加速。然后，后端如何做服务分层，比如接入层、服务层、数据层。接入层可能需要限流、鉴权，服务层处理业务逻辑，数据层用Redis和MySQL。
然后，库存管理是关键，如何用Redis预减库存，避免直接打穿到数据库。同时，超卖问题需要用分布式锁或者Redis的原子操作来保证。还有异步处理订单，比如用消息队列来削峰，将下单操作异步化，减少数据库压力。
另外，需要考虑缓存和数据库的数据一致性，比如预减库存后，如何保证最终扣减数据库库存，以及如何处理失败的情况，比如库存不足时的回滚。
核心代码部分可能需要展示如何用Redis的decrement操作，以及消息队列的生产和消费。比如用Spring Boot的控制器接收请求，先验证用户和秒杀状态，然后Redis预减库存，生成订单ID，发送消息到Kafka，消费者处理数据库操作。
可能的误区是，用户可能认为只需要处理高并发，但忽略了分布式系统的其他方面，比如服务发现、负载均衡、监控和降级策略。还有，如何防止恶意请求，比如同一个用户多次请求，需要限制频率。
另外，测试和压测也是重要的，但用户可能没有提到，但架构设计中需要考虑，比如使用JMeter进行压力测试，确保系统能承受预期流量。
总结下来，整个架构需要从前端到后端，层层优化，使用缓存、消息队列、限流、分布式锁等技术，确保系统在高并发下稳定运行，同时保证数据的一致性和正确性。
构建一个高并发、高可用的电商秒杀系统需要从架构设计、核心逻辑到基础设施进行全面规划。以下为分步解析：
一、架构设计原则
- 系统分层：接入层 -> 服务层 -> 数据层
- 核心目标：
- 削峰填谷（应对瞬时流量）
- 防止超卖（库存一致性）
- 高可用（容灾、熔断降级）
- 关键手段：
- 静态资源CDN加速
- 分布式缓存预减库存
- 异步化订单处理
- 限流与降级
二、架构分层设计
graph TD
A[客户端] -->|CDN| B(Nginx集群)
B -->|限流| C[网关层]
C --> D[服务集群]
D --> E[Redis集群]
D --> F[Kafka]
F --> G[订单服务]
G --> H[MySQL集群]1. 接入层优化
- 静态资源分离：HTML/CSS/JS通过CDN分发
- Nginx限流：令牌桶算法控制请求速率
limit_req_zone $binary_remote_addr zone=seckill:10m rate=100r/s;
location /seckill {
limit_req zone=seckill burst=200 nodelay;
}2. 服务层设计
- 独立秒杀服务：与其他业务解耦
- 热点数据本地缓存：Guava Cache缓存商品信息
- 分布式Session：JWT Token替代Cookie
3. 数据层设计
- Redis集群：库存预减、分布式锁
- Kafka消息队列：订单异步处理
- MySQL分库分表：订单表按用户ID分片
三、核心业务逻辑实现
1. 库存预减方案
// Redis Lua脚本保证原子性
String script =
"if redis.call('exists', KEYS[1]) == 1 then\n" +
" local stock = tonumber(redis.call('get', KEYS[1]))\n" +
" if stock > 0 then\n" +
" redis.call('decr', KEYS[1])\n" +
" return stock - 1\n" +
" end\n" +
" return -1\n" +
"end\n" +
"return -2";2. 秒杀接口伪代码
@RestController
public class SeckillController {
@Autowired
private RedisTemplate redisTemplate;
@PostMapping("/seckill")
public Response seckill(@RequestParam Long itemId, @RequestParam String userId) {
// 1. 校验用户&商品状态
if (isBlackList(userId)) return Response.error("操作频繁");
// 2. Redis预减库存（原子操作）
Long stock = redisTemplate.execute(decStockScript, Collections.singletonList("stock:"+itemId));
if (stock < 0) return Response.error("已售罄");
// 3. 生成临时订单号
String orderId = generateOrderId(userId, itemId);
// 4. 发送MQ消息
kafkaTemplate.send("seckill_orders", new OrderMessage(orderId, userId, itemId));
return Response.success(orderId);
}
} 3. 消息消费者
@KafkaListener(topics = "seckill_orders")
public void processOrder(OrderMessage message) {
try {
// 1. 数据库扣减库存（CAS乐观锁）
int update = itemMapper.reduceStock(
message.getItemId(),
"WHERE stock > 0 AND version = #{version}");
if (update == 0) {
// 库存不足，回滚Redis
redisTemplate.increment("stock:"+message.getItemId());
return;
}
// 2. 创建订单
orderMapper.createOrder(message.getOrderId(),
message.getUserId(), message.getItemId());
} catch (Exception e) {
// 告警+人工补偿
}
}四、关键问题解决方案
1. 超卖问题
- 双重校验：Redis预检 + 数据库乐观锁
- 最终一致性：MQ保证扣减操作最终完成
2. 恶意请求
- 分级限流：
- Nginx层：IP级别限流
- 网关层：Sentinel集群流控
- 服务层：用户ID频率控制（Redis incr）
// 用户10秒内只能请求1次
String key = "limit:" + userId;
if (redisTemplate.opsForValue().increment(key, 1) == 1) {
redisTemplate.expire(key, 10, TimeUnit.SECONDS);
} else {
throw new RuntimeException("请求过于频繁");
}3. 服务降级
- Hystrix熔断：当失败率>50%时熔断
- 降级策略：直接返回"活动太火爆"提示
五、监控与压测
- 监控体系：
- Prometheus监控QPS、库存量、订单延迟
- ELK日志分析异常请求
- 压测工具：
- JMeter模拟10万级并发
- 验证Redis集群吞吐量（目标>10w ops/s）
六、架构演进路线
- 初期：Redis + 数据库事务
- 中期：引入MQ异步削峰
- 成熟期：库存分片（不同商品分配到不同Redis节点）
- 终极方案：业务规则调整（预约+抽签制）
通过以上架构设计，可实现单机QPS从千级提升到十万级，同时保证系统的高可用性和数据一致性。实际落地时需要根据业务规模灵活调整技术选型，例如Redis可替换为阿里云Tair，Kafka可替换为Pulsar等云服务。