写点什么

系统性能优化案例(秒杀系统)

用户头像
积极&丧
关注
发布于: 2020 年 12 月 19 日

性能现状

  • 网站的正常流量情况

  • 并发(单台),高峰期<10;

  • 吞吐量(TPS,单台)高峰期,<60

  • CPU负载Load高峰期,<2,大部分服务器<1;

  • CPU使用率,一般只占1颗核,平均60%左右。

  • 服务器平均响应 高峰期,<150ms;

  • 图片总流量带宽1.8G(各网站总台)

  • 高并发下的风险

  • 网络带宽耗尽

  • 服务器load飙高,停止响应。

  • 数据库瘫痪

  • 高并发下的事故

  • 事故:网站运营推广页面弹出1兆大图片导致带宽耗尽

  • 增加审核机制:运营推广增加的图片流量不能超过现有流量的30%

  • 合作媒体推广:迅雷,暴风影音浮出广告,导致ZZ集群Crash。

  • 秒杀

  • 开业88小时不间断秒杀活动。

  • 高并发对网站性能的影响

高并发实例:开业秒杀活动

  • 商业需求

  • 为庆祝 开业推出88小时不间断秒杀活动。

  • 每小时整点推出8款商品

  • 每款商品供168件,每人限批3件,成交人数56人。

  • CCTV黄金广告时间,各种网络,平面媒体轰炸,总广告费:1.5亿

  • 接到运营通知,距离秒杀开始仅仅5天时间。

  • 技术挑战

  • 瞬间高并发

  • 8000并发:预计秒杀在线人数可达8000人

  • 风险:带宽耗尽。

  • 服务器:崩溃,可以理解成自己给自己准备的D.D.O.S攻击。

  • 秒杀器

  • 第一种:秒杀前不断刷新秒杀页面,直到秒杀开始,抢着下单。

  • 第二种:跳过秒杀页面,直接进入下单页面,下单。

秒杀系统:服务器和网络准备

  • 服务器准备(仅5天时间)

  • style 服务器(Lighttpd集群):5台

  • 图片服务器(Nginx集群):5台

  • 静态服务器(Apache集群):10台

  • 交易服务器(JBoss动态集群):10台

  • 带宽准备

  • 图片出口带宽上线2.5G

  • 出口带宽支持10G,但是图片服务器集群的处理能力=图片服务器集群最大并发处理能力X网站平均图片大小=2.5G

  • CDN准备:Chinacache沟通;借用CCCC CDN

  • 主要依赖CDN,缓存去输出静态资源

  • 注意

  • 单独开发与原来完全隔离。

  • 做新的秒杀系统比在以前系统里面重构扩容,反而简单清晰。

  • 重构先做隔离

秒杀系统:架构目标

  • 图片网络带宽:1.0G

  • 新增图片带宽:必须控制在1.0G左右

  • 每件商品秒杀页面的图片总大小不得超过:1000000/(1000*8)=125K/每商品

  • 网站并发:

  • 每件商品并发:1000【运营商估计】

  • 总并发:8(件商品)X1000(人/商品)=8000

组成

  • 简单系统:

  • 三个页面组成:秒杀商品列表,秒杀商品介绍,下单

  • 静态集群

  • 动态集群

设计原则

  • 静态化

  • 采用js自动更新技术将动态页面转化为静态页面

  • 并发控制,防秒杀器

  • 设置阀门,只放最前面的一部分人进入秒杀系统

  • 简化流程

  • 砍掉不重要的分支流程,如下单页面的所有数据库查询

  • 以下单成功作为秒杀成功标志。支付流程只要在1天内完成即可。

  • 前端优化

  • 采用YSLOW原则提升页面响应速度。

静态化

  • 将不同的静态页面定时去生成好,然后让客户去访问。



  • 秒杀商品列表/秒杀商品介绍页面,如何判断秒杀开始否。

  • valid-offer.js



三道阀门的设计

  • 基于TT的计数器

  • 大量请求被计数器拦截掉,1000并发就可以了,只让前面的人去

秒杀器的预防

  • 秒杀Detail页面

  • URL:随机

  • 秒杀签2秒放出,脚本生成,秒杀前。

  • 1000次访问上线控制【每件商品只能放入1000人浏览】

  • 下单页面

  • 订单ID,随机。

  • 不能直接跳过秒杀Detail页面进入。

  • 每个秒杀商品,带预先生成的随机token作为URL参数。

  • 如果秒杀过,直接跳到秒杀结束页面。

  • 100次访问上线控制【每件商品只能放入1000人下单】

Web Server 调优

  • Apache

  • JBoss

秒杀静态页面优化

  • 图片合并

  • 8张图片合并成1张,css 偏移展示。

  • 减少HTTP请求数,减少请求等待数。

  • 减少发送Cokkies的量

  • HTML内容压缩

  • 图片压缩:图片Bytes<长&宽/2250

  • HTML Header Cache-Control设置

  • CSS,JS精简

  • 部分直接写在页面中,减少HTTP请求次数。

下单页面优化

  • 数据库操作:全部砍掉

  • 原下单页面要访问8次数据库,全部砍掉

  • 秒杀流程精简

  • 砍掉填写或选择收货地址,在秒杀成功后填写。

  • 砍掉调用是否开通支付接口,秒杀首页文案提示必须开通。

  • 采用内存缓存

  • 秒杀Offer数据,支付相关信息,缓存。



交易系统性能优化

  • 关闭 KeepAlive(用户在短时间内连续点击概率很低)

  • JVM优化

  • 优化CMS垃圾回收器的参数

  • 消灭 Top10Bottlenecks

  • Velocity参数调优

  • 采用DBCP1.4替换C3P0

  • Offer产品参数的XML解析。

二跳页面的优化

  • 其他页面

  • 前端优化:Yslow规则调优

  • 减少HTTP请求,合并js,css,图片,充分利用浏览器缓存。

  • 图片压缩,公式

  • 避免发生Cookies

  • 交易系统优化

  • 普通订单管理列表和XXXX秒批订单管理列表分离

  • 禁止用模糊查询功能。

应急预案



改进采用更轻量/快速的服务器

  • 采用Lighttpd替代Apache杀手锏(AIO)











用户头像

积极&丧

关注

还未添加个人签名 2019.02.13 加入

还未添加个人简介

评论

发布
暂无评论
系统性能优化案例(秒杀系统)