秒杀系统设计

教程：我的极客购买课程

笔记：

 

一、秒杀系统都有哪些关键点

并发读

并发写

 

请求数据尽量少

请求路径尽量短

依赖尽量少

避免单点

 

概括为：稳准快

 系统架构要满足高可用，流量符合预期，就是超出预期也不能掉链子

 秒杀10台爱疯，只能卖10台，不能多不能少

 系统要快

------------------------------------------------------------------------------

二、做好动静分离

 数据动静分离

  1. 提升单次请求的效率

  2. 减少没必要的请求

  

 缓存节点：用户浏览器 CDN 服务器缓存中

  

 

------------------------------------------------------------------------------

三、“二八原则”有针对性的处理好“热点数据”

 静态热点数据

  可以提前预测出来

 

 动态热点数据

  临时出现的热点数据（比如卖家再抖音做广告，产品瞬间成为热点数据）

 

 处理热点数据：

  一是优化：缓存，可以采用LRU淘汰算法替换

  二是限制：一种保护机制

  三是隔离：不要让1%的请求影响另外的99%

   业务隔离：把秒杀做成一种营销活动，独立于主题业务去实现

   系统隔离：分组部署

   数据隔离：启用单独的Cache集群或者MySql数据库来存放热点数据

  

-------------------------------------------------------------------------------

四、 流量消峰（缓存瞬时流量）

 

排队缓存请求

1. 消息队列

2. 线程池加锁等待

3. 内存排队

4. 请求序列化到文件中，再来读文件

 

 

秒杀答题

1. 防止秒杀器作弊，筛选出有效请求

2. 延缓请求，让流量平稳的进入系统，把峰值的下单请求拉长，从1秒之内延长到2-10秒

   --1. 题库生成模块：生成一个个问题和答案，并不需要很复杂，但要防止机器可以算出结果

   --2. 题库的推送模块：在秒杀开始前，提前将题目推送到详情系统和交易系统

   --3. 题目的图片生成模块：用于把题目生成图片格式，并在图片里加一些干扰因素，图片提前推送到CDN上并进行预热

   

分层过滤

核心思想：在不同的层次尽量过滤掉无效请求，让漏洞最末端才是最有效的

CDN << 前台读系统（如商品详情系统） << 后台写系统（如交易系统） << 数据层（DB）

 

CDN :资源从用户浏览器或CDN中获取

前台系统：允许数据的脏读，尽量走Cache

后台系统：做数据的二次校验

数据层：完成数据的一致性校验

 

 

分层的目的：

 1. 在读系统中，尽量减少由于一致性校验到来的瓶颈，但是尽量将不影响性能的检查条件提前，如：用户是否具有秒杀资格、商品状态是否正常、用户答题是否正确、秒杀是否已经结束、是否非法请求、营销等价物是否充足等

 2. 在写系统中，主要对写做一致性检查，最后在数据库层保证数据的最终准确性

---------------------------------------------------------------------------------

五、影响性能的几个因素

 

1. QPS、响应时间（RT）、

 

总QPS=(1000ms/响应时间) * 线程数量

 

 一个是一次响应服务端耗时

 一个时处理响应的线程数

 

 要减少CPU的执行时间

 

 

 线程数越多，线程的切换成本就越高，而且线程也会消耗一定量的内存

 合理线程数默认配置：多线程中的线程数配置：线程数=2*CPU核数+1

 最佳实践配置：线程数=（线程等待时间+线程CPU时间）/线程CPU时间 * CPU数量

 

 

 如何发现瓶颈：IO、内存、磁盘、网络等

 缓存系统来说---》内存

 存储系统来说---》IO

 秒杀系统来说---》CPU

 

 如何发现发现CPU瓶颈？

  JProfiler、Yourkit工具：他可以列出整个请求中每个函数的CPU执行时间，你便可以发现哪个函数耗时最多

  

 如何优化系统：

 Java：减少序列化、减少编码、并发读优化、减少数据、数据分级（动静分离）、减少中间环节、增加预处理环节

-----------------------------------------------------------------------------------

六、秒杀系统中如何设计减库存

 

 减库存的阶段：下单阶段？付款阶段？

  下单减库存

   竞争中，恶意下单，不去付款，影响卖家的商品销售

  付款减库存

   100件商品，会出现300人下单的情况，多数人下了单但是付不了款，用户体验差

  预扣库存

   下单时间预扣，规定时间内不付款，再释放库存

   但是恶意买家，10分钟后再继续下单，甚至可以一次下单多件商品，这要结合反作弊机制去限制

   

  解决并发锁：

   1. 应用层做排队（多集群负载，可能不太理想）

   2. 数据库层做排队（MySql层面阿里开源的排队补丁，目前已开源）

------------------------------------------------------------------------------------

七、如何设计兜底方案

  遇到访问量大时，导致宕机，所以要控制流量，设计Plan B 最坏情况下的兜底方案

  

  高可用系统建设

  1. 架构阶段

   异步容灾

   异步化

   分组隔离

   避免单点

  2. 编码阶段

   限流保护

   超时处理

   异步线程

   错误捕获

  3. 测试阶段

   beta测试

   自动化对比测试

  4. 发布阶段

   分批发布

   多版本发布

  5. 运行阶段

   数据对账

   自动降级

   过载保护

   实时监控报警

  6. 故障发生

   快速回复

   故障定位

  

  降级：开关系统

   过载时，关闭到部分功能

 

  限流系统：

   客户端限流

   服务端限流

   

  拒绝服务