秒杀系统作为互联网“高并发、高性能、高可用”系统的代表，从系统设计、数据处理到运维保障等方面都有很多可以考察和深挖的点，本文将尝试分析涉及的关键问题，并总结相关的最佳实践。

秒杀系统的核心挑战在于平衡性能、一致性与安全性。

秒杀系统中常见的问题包括：超卖问题、高并发性能瓶颈、数据一致性问题、分布式锁失效、事务管理失效、安全与放作弊问题、系统监控与运维等。

通过分层架构（如流量削峰、异步化）、原子操作（如Lua脚本）、分布式协调（如Redis锁）及全周期管理（监控+应急预案）综合解决。设计时应优先保障核心链路（如库存扣减），非核心功能（如积分赠送）允许降级或最终一致性。

从“高并发、高性能、高可用”来看

高并发

1. 限流
   • 流量削峰漏斗：业务校验分层过滤（如，账号安全、购买资格->系统基本信息->商品信息->秒杀时间->数据库写操作）
   • 接口限流：借助现有组件，如Sentinel
   • 问题、验证码：避免请求集中、解决脚本作弊等问题（如，对正确性校验、对提交时间校验）
   • 提前预约：提前筛选黄牛

高性能

也关于高并发

1. 热点数据隔离：分为静态和动态
   • 静态数据基本不变，例如商品信息等：利用CDN内容分发服务器
   • 动态数据高频变化，例如库存等：
     • 多级缓存
       • 缓存预热
       • 缓存失效时长控制
       • 本地缓存LocalCache
       • 少量极热数据可以放在JVM
     • 涉及另一个问题：识别热点key
       • 中间件层面：如京东零售的hotkey

高可用

1. 集群化
2. 流量削峰：借助消息队列
3. 降级：优先保证核心业务（应对系统自身的故障）
4. 熔断：中断对该服务的调用（应对系统依赖外部系统或第三方的故障）

从数据一致性来看

扣减库存方案

首先常见的方案包括下单扣减库存（常用）和付款扣减库存，另外超时不付款则释放库存。

一个很常见的是超卖问题。其解决方案：

• 提前把商品信息放到缓存（考虑分布式缓存）
• 通过lua脚本操作Redis，执行原子性操作
• 数据库唯一键

余额扣减方案

• 并发高：悲观锁
  • 数据库的排他锁
• 并发不高：乐观锁
  • 版本号机制 （注意ABA问题）

系统架构设计

以阿里电影节为例

架构设计上，介入统一网关进行安全保障和限流，库存和订单的数据隔离，加入多级缓存：

业务设计上，对外业务和后台管理可以分开。内网的业务服务、基础服务和中间件分开：

其他

针对恶意操作

• 库存失效时间
• 限制用户购买数量
• 黄牛防控系统

性能测试

• 常用工具
  • Jmeter
  • LoadRunner
  • Galtling
  • ab

其他：

• 精准监控
• 数据大盘

接口幂等

• 状态机
• 分布式锁

—作为项目挖掘机的记录……待补充完善……