01.16 Day 32 - 性能设计篇之“秒杀”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 32 天，也是我第 32 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《性能设计篇之“秒杀”》的文章。

关键词总结：秒杀流程（用户角度、技术角度）、秒杀技术挑战（百万 TPS、热点数据）、秒杀解决方案（引入 CDN、CDN 边缘节点、统计数据、概率值、放行的数据量）、更多思考（适合使用边缘节点的场景、适合使用边缘节点的场景）。

 

所学总结：

 

秒杀流程

用户角度

• 准备秒杀的着陆页（Landing Page），展示一个倒计时的按钮；
• 到时间点亮按钮，潜在用户可以对其进行点击操作；
• 需要做验证操作以防非人为抢单操作。

技术角度

• 前端不停的轮询查询后端看是否已准备就绪；
• 后端在前端的每一次轮询查询之后会返回一个准确的时间用以校对前端显示的时间；
• 当后端就绪时会返回一个地址；
• 地址将与按钮做关联；
• 如果在点击之后抢到库存，就进入支付页面，没抢到则返回秒杀已结束。
   

秒杀技术挑战

百万 TPS

百万并发会导致网站奔溃，网络带宽也不够用。理论上来说，百万 TPS 是需要非常多机器的。

热点数据

请求会集中在同一条数据库记录，分库分表也不会好转，因为这是单条热点数据。
 

秒杀解决方案

引入 CDN

让 CDN 来缓存这一个页面以供百万用户同时访问。

CDN 边缘节点

让几十上百的 CDN 边缘节点来均衡分担百万用户的请求。

统计数据

通过 CDN 节点上的服务来统计每个节点上的总用户数并回传至中心。

概率值

按照百分比划分可放行用户量，百万的 0.03% 就是 300。也就是一万里只有 300 人的请求会被放行，其余的请求会被丢弃并显示活动结束。

放行的数据量

百万用户的 0.03% 就是 300 个用户，产生的 TPS 是 300，这个并发量是可以处理的。
 

更多思考

不适合使用边缘节点的场景

像双十一这样有各种复杂的业务逻辑以及第三方调用于一体的应用不适合用边缘节点。双十一需要考虑的方面：性能调整、性能规划、分布式弹力设计、性能测试、系统瓶颈、水平扩展。

适合使用边缘节点的场景

像外卖、共享单车、打车这些有地域特征的业务的一些简单业务逻辑就比较适合使用边缘节点。

 

末了

重新总结了一下文中提到的内容：秒杀业务流程、技术挑战、解决方案、抢车票问题、双十一问题、高并发架构、CDN 边缘节点计算、适合使用边缘节点的场景。