Java场景题:支持高并发的秒杀系统设计
-
【前端设计】
- 静态资源(如商品详情页)通过CDN或浏览器缓存分发
- 前端添加限流策略(如用户点击后置灰按钮),减少无效请求
- 延缓用户请求(如数学题、滑块验证),过滤机器人
- 请求随机延迟:前端随机增加 50-200ms 延迟提交,避免请求同时到达后端
【后端设计】
- 网关层
- 限流(令牌桶/漏桶算法/IP限流):拦截大部分请求,直接返回秒杀失败
- 熔断:当某个依赖服务(如数据库、第三方接口)的故障率超过阈值时,系统会自动暂时切断对该服务的调用,避免因持续请求导致资源耗尽或雪崩效应。熔断后,系统会快速失败(Fallback)或返回兜底结果
- 降级:主动牺牲非核心功能或服务质量,优先保障核心业务流程的可用性。通过预定义的兜底策略(如返回缓存数据、简化逻辑)减轻系统压力。
- 请求鉴权、登录验证
- 服务层
- 请求数据校验
- 如使用布隆过滤器快速拦截不合理的请求,防止缓存穿透
- 拦截不合法的秒杀请求,例如部分商品还没到秒杀时间,不让购买
- 对热点数据进行Redis缓存预热(如库存),提升读性能
- 热点数据识别
- 报名打标(卖家主动报名参与秒杀活动,系统对报名商品打上特定标签)
- 历史数据分析(如Top N商品)
- 热点数据识别
- 使用Redis+Lua脚本实现原子化库存预扣
- 将耗时的操作(如订单创建、库存扣减)放到消息队列,异步执行,实现流量消峰,避免瞬时压力击垮数据库
- 数据库读写分离、分库分表、冷热分离
- 要应对高并发,后端使用微服务架构,核心逻辑拆分为独立服务(如库存服务、订单服务),采用无状态设计便于水平扩展
- 秒杀逻辑专门封装到第一个服务,多部署一些机器,也可以专门使用一些Redis集群和数据库
- 通过K8s实现自动扩容、缩容,应对突发流量
- 请求数据校验
- 注意事项
- 避免跨服务RPC
- 代码要优化好,减少锁竞争
- SQL性能要优化好
- 分布式事务问题,保证数据最终一致
- 消息队列消费幂等性
- 服务和中间件都要集群,避免单点故障(异地多活)
- 根据预估流量,提前做好压力测试,预览多余算力