itechub / seckill-django

⏲简单秒杀需求实现

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 问题,最优实践?

About

⏲简单秒杀需求实现


Languages

Language:Python 91.5%Language:Shell 5.1%Language:Dockerfile 3.3%