Java场景题：支持高并发的秒杀系统设计

【前端设计】

• 静态资源（如商品详情页）通过CDN或浏览器缓存分发
• 前端添加限流策略（如用户点击后置灰按钮），减少无效请求
• 延缓用户请求（如数学题、滑块验证），过滤机器人
• 请求随机延迟：前端随机增加 50-200ms 延迟提交，避免请求同时到达后端

【后端设计】

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