【Java 开发日记】设计一个支持万人同时抢购商品的秒杀系统？

Ne0inhk

— 10 min read
【Java 开发日记】设计一个支持万人同时抢购商品的秒杀系统？

目录

一、系统架构设计

1. 分层架构

2. 具体组件

二、核心问题解决方案

1. 超卖问题

解决方案一：Redis原子操作

解决方案二：数据库乐观锁

解决方案三：预扣库存

2. 高并发请求处理

2.1 流量削峰

2.2 分层过滤

3. 系统性能优化

3.1 缓存策略

3.2 读多写少优化

4. 详细实现方案

4.1 秒杀流程

4.2 库存同步方案

三、高可用保障

1. 限流降级策略

2. 熔断降级

四、监控与告警

1. 关键监控指标

2. 监控实现

五、部署与扩展

1. 弹性扩展策略

2. 压测方案

六、安全考虑

总结要点

面试回答

一、系统架构设计

1. 分层架构

客户端层 → 接入层 → 业务服务层 → 数据层 ↓ ↓ ↓ ↓ 限流 缓存 队列 数据库

2. 具体组件

  • 客户端：静态资源CDN、倒计时校准、防重复提交
  • 接入层：Nginx+Lua/OpenResty，做第一层限流和缓存
  • 业务层：
    • 秒杀服务集群（无状态）
    • 消息队列（Kafka/RocketMQ）
    • 缓存集群（Redis Cluster）
  • 数据层：
    • 主从数据库（读写分离）
    • 分库分表（按商品/时间）

二、核心问题解决方案

1. 超卖问题

解决方案一：Redis原子操作
# 使用Redis的DECR原子操作扣减库存 def deduct_stock(product_id, user_id): stock_key = f"stock:{product_id}" # Lua脚本保证原子性" local stock = tonumber(redis.call('GET', KEYS[1])) if stock and stock > 0 then redis.call('DECR', KEYS[1]) return 1 end return 0 """ result = redis.eval(lua_script, 1, stock_key) return result == 1
解决方案二：数据库乐观锁
UPDATE products SET stock = stock - 1, version = version + 1 WHERE id = ? AND stock > 0 AND version = ?
解决方案三：预扣库存
// 先预扣Redis库存，再异步同步到DB public boolean preDeductStock(String productId, int count) { String key = "seckill:stock:" + productId; Long remaining = redisTemplate.opsForValue().decrement(key, count); if (remaining >= 0) { // 发送MQ消息异步扣减数据库 sendStockDeductMessage(productId, count); return true; } else { // 库存不足，回滚 redisTemplate.opsForValue().increment(key, count); return false; } }

2. 高并发请求处理

2.1 流量削峰
// 使用消息队列缓冲请求 @Component public class SeckillService { @Autowired private RocketMQTemplate mqTemplate; public SeckillResult seckill(SeckillRequest request) { // 1. 校验用户和商品状态 if (!validate(request)) { return SeckillResult.fail("校验失败"); } // 2. 生成唯一请求ID String requestId = generateRequestId(request); // 3. 请求入队，立即返回 mqTemplate.sendOneWay("seckill-topic", MessageBuilder.withPayload(request).build()); // 4. 返回排队中状态，前端轮询结果 return SeckillResult.processing(requestId); } }
2.2 分层过滤
所有请求 → 合法性校验 → 库存校验 → 频率控制 → 实际下单 ↓ ↓ ↓ ↓ ↓ 100万 50万 10万 5万 1万

3. 系统性能优化

3.1 缓存策略
# 多级缓存配置 缓存层级: 一级: JVM本地缓存 (Caffeine) - 热点商品 二级: Redis集群 - 库存信息 三级: 数据库 - 最终一致性
3.2 读多写少优化
// 商品信息缓存预热 @Service public class CacheWarmUpService { @PostConstruct public void warmUpSeckillProducts() { List<Product> hotProducts = loadHotProducts(); for (Product product : hotProducts) { // 库存信息 redisTemplate.opsForValue().set( "stock:" + product.getId(), product.getStock() ); // 商品详情 redisTemplate.opsForValue().set( "product:" + product.getId(), JSON.toJSONString(product) ); // 使用布隆过滤器存储可售商品ID bloomFilter.add(product.getId()); } } }

4. 详细实现方案

4.1 秒杀流程
class SeckillSystem: def process_seckill(self, user_id, product_id): # 1. 恶意请求拦截 if not self.check_risk(user_id): return {"code": 403, "msg": "访问过于频繁"} # 2. 布隆过滤器快速判断 if not bloom_filter.contains(product_id): return {"code": 404, "msg": "商品不存在"} # 3. 内存标记（已售罄的商品直接返回） if sold_out_flags.get(product_id): return {"code": 400, "msg": "已售罄"} # 4. Redis原子扣减库存 if not self.deduct_stock_in_redis(product_id): sold_out_flags[product_id] = True return {"code": 400, "msg": "库存不足"} # 5. 生成订单ID（雪花算法） order_id = snowflake.generate() # 6. 订单信息入队 mq.send({ "order_id": order_id, "user_id": user_id, "product_id": product_id, "time": time.time() }) # 7. 返回排队中 return { "code": 200, "msg": "排队中", "order_id": order_id, "queue_position": get_queue_position(order_id) }
4.2 库存同步方案
@Component @Slf4j public class StockSyncService { // 数据库最终扣减 @Transactional public void syncStockToDB(String productId, int count) { try { // 数据库扣减（带重试机制） boolean success = productDAO.deductStock(productId, count); if (success) { // 更新Redis中的最终库存状态 redisTemplate.opsForValue().set( "stock_final:" + productId, getDBStock(productId) ); // 删除售罄标记 soldOutCache.remove(productId); } } catch (Exception e) { log.error("库存同步失败", e); // 记录异常，人工介入处理 alertService.sendAlert(e); } } // 库存对账任务 @Scheduled(cron = "0 */5 * * * ?") public void stockReconciliation() { List<Product> products = productDAO.getAllSeckillProducts(); for (Product product : products) { Integer redisStock = getRedisStock(product.getId()); Integer dbStock = product.getStock(); if (!Objects.equals(redisStock, dbStock)) { log.warn("库存不一致: productId={}, redis={}, db={}", product.getId(), redisStock, dbStock); // 自动修复或报警 fixStockInconsistency(product.getId(), dbStock); } } } }

三、高可用保障

1. 限流降级策略

# 多维度限流配置 限流规则: 用户维度: 每个用户10次/分钟 IP维度: 每个IP 1000次/分钟 商品维度: 每个商品 10000次/分钟 总QPS: 系统最大承受50000 QPS

2. 熔断降级

@RestController @Slf4j public class SeckillController { @GetMapping("/seckill/{productId}") @HystrixCommand( fallbackMethod = "seckillFallback", commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"), @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20") } ) public Response seckill(@PathVariable String productId, @RequestParam String userId) { return seckillService.process(userId, productId); } // 降级方法 public Response seckillFallback(String productId, String userId) { return Response.error("系统繁忙，请稍后重试"); } }

四、监控与告警

1. 关键监控指标

  • 系统层面：QPS、RT、错误率、CPU/内存使用率
  • 应用层面：库存扣减成功率、消息堆积量
  • 业务层面：抢购成功率、用户排队时长

2. 监控实现

@Component public class SeckillMonitor { private final MeterRegistry meterRegistry; // 记录关键指标 public void recordSeckill(String productId, boolean success, long cost) { // QPS监控 meterRegistry.counter("seckill.requests.total").increment(); if (success) { meterRegistry.counter("seckill.success.total").increment(); } else { meterRegistry.counter("seckill.fail.total").increment(); } // 耗时分布 meterRegistry.timer("seckill.process.time") .record(cost, TimeUnit.MILLISECONDS); // 库存变化 meterRegistry.gauge("seckill.stock." + productId, getCurrentStock(productId)); } }

五、部署与扩展

1. 弹性扩展策略

  • 水平扩展：无状态服务可快速扩容
  • 自动伸缩：基于CPU使用率或QPS自动扩缩容
  • 异地多活：重要业务支持多机房部署

2. 压测方案

压测场景: 场景1: 库存预热，10万用户同时抢1万商品 场景2: 持续高压，5万QPS持续5分钟 场景3: 峰值冲击，瞬间20万QPS 压测目标: 成功率: >99.9% 平均RT: <100ms 错误率: <0.1%

六、安全考虑

  • 防刷机制：
    1. 验证码（峰值时降级）
    2. 设备指纹
    3. 行为分析
  • 数据安全：
    1. 关键数据加密
    2. 操作日志记录
    3. 防篡改校验

总结要点

  1. 架构核心：分层过滤 + 异步处理 + 最终一致
  2. 库存核心：Redis原子操作 + 消息队列 + 数据库乐观锁
  3. 性能核心：缓存预热 + 流量削峰 + 读写分离
  4. 稳定核心：熔断降级 + 限流隔离 + 快速失败

面试回答

首先，架构设计上要动静分离、分层削峰。我会把系统分为：

  1. 静态资源分离：商品图片、描述页等提前推送到CDN，请求直接走边缘节点，不给后端压力。
  2. 网关层限流：在入口用Nginx或网关（如Sentinel）做恶意请求拦截和总流量限制，比如对同一UID限速，超过阈值直接返回“请求频繁”。
  3. 业务逻辑后置，请求队列化：秒杀的核心——“下单扣库存”这个最重要的逻辑，绝不放在前台实时处理。用户点击“抢购”后，前端直接返回“排队中”，请求进入一个消息队列（比如RabbitMQ、Kafka或RocketMQ）。这样一来，海量并发就被平滑成顺序处理的流量，后端服务按照自己的能力从队列里慢慢消费，实现削峰填谷。
  4. 服务独立部署：把秒杀相关的功能（验资格、扣库存）单独做成一个微服务，避免影响商城其他正常功能（如浏览、普通下单）。

其次，针对如何解决超卖、库存扣减和高并发请求这三个核心问题，我的解决方案是：

  • 解决超卖和库存扣减：这是秒杀的核心。我的方案是：
    • 预扣库存：活动开始前，把商品的库存从主库加载到Redis中。Redis是单线程内存操作，可以保证原子性。
    • 原子化操作：在Redis里，使用 DECR 或 LUA 脚本来扣减库存。DECR 命令会直接返回扣减后的值，如果返回值小于0，就说明库存没了，后续流程直接返回售罄。LUA脚本可以打包多个操作（检查库存、扣减），确保整个过程原子性，彻底杜绝超卖。、
    • 最终同步：后台服务从队列消费，成功扣减Redis库存后，生成一个订单ID（但状态是“未支付”），再异步去更新数据库的库存。这里数据库的库存更多是用于后续对账和长尾查询。
  • 应对高并发请求：
    • 限流：除了网关层的总限流，在秒杀服务本身也要做限流，比如用信号量或令牌桶控制处理线程数，只服务自己能承受的流量，多的直接拒绝，快速失败。
    • 无状态化与扩容：秒杀服务做成无状态的，方便用K8s或云服务快速横向扩容，扛过峰值后再缩容，控制成本。
    • 热点数据隔离：对于“爆款”商品，它的库存Key在Redis里是热点Key。可以做两件事：一是提前对它进行Key散列，把压力分散到多个Redis节点；二是使用Redis集群模式，并开启读写分离。

最后，还有一些关键的细节和兜底策略：

  • 防刷与验证：前端加入计算型验证码或答题，防止机器人；下单前必须校验用户资格（是否登录、地址完善等）。
  • 异步下单与结果轮询：用户提交后，服务端返回一个“排队ID”，前端用这个ID轮询后端，查询最终结果（成功、失败或等待）。用户体验上是“排队等待”，而不是一直卡住或报错。
  • 数据一致性对账：因为用了Redis和消息队列，可能出现极端情况下的数据不一致（比如Redis扣成功，但下游服务挂了，订单没生成）。需要有一个定时对账任务，核对Redis、数据库库存和订单状态，进行修复。
  • 降级与熔断：如果Redis或数据库访问慢，要有熔断机制，防止服务被拖垮。比如可以快速降级到“返回售罄”的静态页面。

总结一下，我的设计思路是：前端限流拦截，请求队列削峰；Redis原子扣减防超卖；服务无状态化应对高并发；再通过异步、对账等手段保证最终一致性和用户体验。

如果小假的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！

Read more

JAVA 泛型与通配符：从原理到实战应用

JAVA 泛型与通配符：从原理到实战应用

JAVA 泛型与通配符：从原理到实战应用 1.1 本章学习目标与重点 💡 掌握泛型的核心概念与设计初衷，理解泛型的编译期检查机制。 💡 熟练使用泛型类、泛型接口和泛型方法，解决数据类型安全问题。 💡 理解通配符（?）、上界通配符（? extends T）和下界通配符（? super T）的使用场景。 ⚠️ 本章重点是 泛型的擦除机制 和 通配符的灵活运用，这是提升代码通用性和安全性的关键。 1.2 泛型的核心概念与设计初衷 1.2.1 为什么需要泛型 在没有泛型的 JDK 5 之前，集合类只能存储 Object 类型的对象。获取元素时需要强制类型转换，这会带来两个严重问题： 1. 类型不安全：可以向集合中添加任意类型的对象，运行时可能抛出 ClassCastException。 2. 代码臃肿：频繁的强制类型转换会让代码可读性和维护性变差。 💡 泛型的出现就是为了解决这些问题，它的核心思想是

By Ne0inhk
【C++笔记】STL详解：vector容器的实现

【C++笔记】STL详解：vector容器的实现

前言：         在学习了vector类的基本使用的前提下，本文将重点分析vector类的常用接口及其应用实现。          一、vector成员变量          vector本质上是一个动态数组，通过原生指针来实现底层维护，为了使得STL接口调用的统一性，我们需要将原生指针重命名为迭代器。          其核心目的是：将数据结构（容器）与操作（算法）分离，并通过一种统一的接口（迭代器）将它们粘合在一起。          成员变量分析 template <class T> class vector { public: // 将原生指针重命名为迭代器，实现接口统一 typedef T* iterator; typedef const T* const_iterator; private: iterator _start; // 指向目前使用空间的头 iterator _finish; // 指向目前使用空间的尾 iterator _end_of_storage; // 指向目前可用空间的尾 };          成员变量分析：

By Ne0inhk
JAVA 多线程编程：从基础原理到实战应用

JAVA 多线程编程：从基础原理到实战应用

JAVA 多线程编程：从基础原理到实战应用 1.1 本章学习目标与重点 💡 掌握线程的核心概念，理解进程与线程的区别和联系。 💡 熟练掌握线程的三种创建方式，理解线程的生命周期及状态转换。 💡 掌握线程同步与锁机制，解决多线程并发安全问题。 💡 了解线程池的核心原理与使用方法，提升多线程程序性能。 ⚠️ 本章重点是 线程同步机制 和 线程池的实战应用，这是多线程开发中的核心难点和高频考点。 1.2 多线程核心概念 1.2.1 进程与线程的区别 💡 进程是操作系统进行资源分配和调度的基本单位，每个进程都有独立的内存空间和系统资源。比如打开一个 Java 程序，就会启动一个进程。 💡 线程是进程的执行单元，是 CPU 调度和执行的基本单位。一个进程可以包含多个线程，这些线程共享进程的内存空间和资源。 对比维度进程线程资源分配拥有独立的内存空间和资源共享所属进程的内存和资源开销成本创建和销毁开销大创建和销毁开销小调度方式由操作系统内核调度由进程内部调度独立性进程之间相互独立线程之间共享资源，依赖性强 ✅ 核心结论：线程是轻量级的进程，多线程编程可以充分利

By Ne0inhk
Java分层开发必知：PO、BO、DTO、VO、POJO概念详解

Java分层开发必知：PO、BO、DTO、VO、POJO概念详解

目录 * 引言 * 一、核心概念与定义 * 1、PO（Persistent Object，持久化对象） * 2、BO（Business Object，业务对象） * 3、DTO（Data Transfer Object，数据传输对象） * 4、VO（View Object，视图对象） * 5、POJO（Plain Ordinary Java Object，简单Java对象） * 二、对比与区别 * 1、表格对比 * 2、关键区别 * 3、流转图 * 总结 引言 在Java企业级开发中，我们经常会遇到POJO、PO、DTO、BO、VO等各种对象概念，这些看似相似的术语常常让开发者感到困惑。本文将深入解析这些核心概念的区别与联系，

By Ne0inhk