README.md

Seckill Django

原始需求：

编写一个 web 服务实现大量用户抢购某个商品的功能。要求：

1. 提供一个 web API，可以基于 HTTP 或 TCP，输入为一个用户 ID，输出该用户是否抢到商品；
2. 最终被抢到的商品的数量要等于库存数量；
3. 每个用户会连续发送两次抢购请求（无论第一次抢没抢到），但是系统要保证一个用户最多只能抢到一个商品，不能多抢，最终抢到商品的用户数应该等于商品的库存数；
4. 用户 ID 数至少是商品库存数的 100 倍；
5. 抢购请求的吞吐量要超过关系式数据库处理能力至少一倍；
6. 用户是否抢到商品的结果要持久化到磁盘上，重启服务后仍能查询到结果；
7. 提供 web API 的程序只在一台电脑上运行，不做集群和负载均衡。

需求拆解

根据业务编写 API

• 简单业务分析
  • 商品
  • 用户
  • 秒杀活动
• 相关的 DB 表设计
• 接口设计及实现
• 对应服务实现
• 测试相关功能
• 打包部署发布

调整优化

1. 引入缓存使用
2. 引入消息队列
3. 测试相关功能

基础使用 JMeter

模拟多用户发起请求，每个用户发起两次请求

如何量化测试基准

1. Docker 进行资源限制，保证运行环境及基础设施的一致性
2. JMeter 多次 load test 取均值
3. 多次测试参照结果数据
4. 根据业务调整对应的测试参数

拓展

• 功能优化
  • 用户友好度（UI 优化）
  • 秒杀活动细化（模拟主流秒杀功能）
• 性能优化
  • 代码优化，进一步梳理业务流程，围绕 CAP 展开
  • 采用不同的 web 框架，或者编程语言实现，如采用异步框架实现，进行性能对比
  • 计算资源类比
    • 垂直拓展 提高容器资源限制，参照结果
    • 水平拓展 集群拓展

原则

1. 参照已有设计 关键字搜索
2. 快速原型实现
3. 保持好的实践

最后的思考总结

1. 秒杀业务真正痛点在哪里
2. 分布式绕不过的 CAP 问题，最优实践？