极客大学架构师训练营 秒杀 爬虫 搜索引擎 Lucene Elastic Search 第 18 课 听课总结

用户头像
John(易筋)
关注
发布于: 2020 年 08 月 06 日

说明

讲师:李智慧



架构师要站顶层高度思考问题:Linux、JVM为啥这么做架构设计,这么做的好处是什么?任何系统,都是软件,跟普通的软件没有什么区别,要找到架构设计的美。



互联网最主要解决大量流量访问的场景下,解决系统高性能的问题。这就是为什么需要这么多方法去解决遇到的高性能问题。



秒杀

秒杀:有限的商品,很多人过来购买。秒杀本身就是一种营销活动。



2009年左右,淘宝搞过1元秒杀买宝马汽车。低配的宝马20万左右,吸引上百万的用户过来抢,平均下来每个用户的广告成本也就几毛钱甚至几分钱,是相当划算的。



案例:XXX 网站性能现状(2009年左右)

吞吐量 = 1/响应时间 1000 并发数;



XXX 网站的正常流量情况

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

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

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

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

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

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



高并发下的风险

  • 网络带宽耗尽。(一张图片几百k,上万人访问,就上千M的图片。)

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

  • 数据库瘫痪。



高并发下的事故

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

☞ 增加审核机制:运营推广增加的图片流量不能超过现有流量的 30%。(通过限制图片大小控制。)

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



秒杀

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



温馨提醒:

首页一般不用访问数据库,因为访问量太大了。如果要做个性化推荐,可以通过搜索引擎返回,也不用访问数据库。



高并发对网站性能的影响

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

商业需求

  • 为庆祝 XXX.com 开业退出 88 小时不间断秒杀活动。

  • 每小时整点退出 8 款商品...

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

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

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



技术挑战

  • 瞬间高并发

☞ 8000 并发:预估秒杀在线人数可达 8000 人。

☞ 风险:带宽耗尽。

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

  • 秒杀器

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

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



当年接下来的架构师,现在年薪上千万。

如果是架构师你接下来,你的思路是什么?



思路:

  1. 公司10年左右的系统,即使重构系统,5天性能提升也只能是百分之几十。

  2. 如果重构旧系统,要跟很多山头的人打交道,牵扯到上百上千人,是很难的。

  3. 做一个新系统,5天是可以搞定的。



架构师的机会:做新东西,是低风险,高回报的。(马云在内的众目睽睽看着,做成了肯定走上人生巅峰。)



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

服务器准备(距离秒杀仅5天时间来不及采购)

  • style 服务器 (Lighttpd 集群:js、css、html资源):5台

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

  • 静态服务器(Apache集群,接入HTTP请求):10台

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



带宽准备

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

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



XXX.com 秒杀系统:架构目标

  1. 图片网络带宽: 1.0G

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

每件商品秒杀的图片总大小不得超过: 1,000,000/(1,000*8) = 125K/每个商品

  1. 网站并发:

单间商品并发:1000【来自运营的预估】

总并发: 8 (件商品) X 1000 (人/商品) = 8000

XXX.com 秒杀系统:组成

简单系统:

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

下单成功后,进入支付系统,走支付流程。



XXX.com 秒杀系统:设计原则

静态化

  • 采用 JS 自动更新技术将动态页面转化为静态页面。(为运营人员开发,上传秒杀商品信息,转换为静态页面的运营系统。)



并发控制,防秒杀器

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



简化流程

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

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



前端优化

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



XXX 秒杀系统:静态化(1)

秒杀商品 List 和 Detail 是静态的 HTML 页面



秒杀系统:静态化(2)

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

  • 答案: valid-offer.js var valid_offerIds = 23624364, 53778658, 35885833, 46999696, 5006797057.



每次只更新valid-offer.js, 这个js返回,哪些商品可以秒杀。同时返回秒杀商品的url。

三道阀门的设计

阀门:基于 TT 的计数器



秒杀器的预防

秒杀 商品详情页面

  • URL: 随机

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

  • 1000次访问上限控制【每件商品只能放入1000人流量】。



SetEnvIfNoCase Referer "^http://1688\.com/" local_ref=1
<FilesMatch "\.(htm|html)">
Order Allow, Deny
Allow from env=local_ref
</FilesMatch>



下单页面:

  • 订单ID,随机。

  • 不能直接跳过秒杀 商品详情页面 进入。

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

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

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



Web Server 调优 - Apache 调优

  • KeepAlive 相关参数调优

  • 其它参数调优: HostnameLookups 设为 off,对 allowfromdomain 等候的域名不进行正向和反向的 dns 解析。

  • 关闭 cookies-log 日志

  • 打开 Linux sendfile()

  • 关闭无用的 module

☞ mod_Gzip

☞ 秒杀页面,非图片 HTML 文本所占流量比重可忽略不计,zip意义不大。

☞ mod_Beacon

☞ mod_hummock (等待反应过来,秒杀已经 over 了)



Timeout 30
KeepAlice On
MaxKeepAliveRequests 1000
KeepAliveTimeout 30
<IfModule worker.c>
StartServers 5
MaxClients 1024
MinSpareThreads 25
MaxSpareThreads 64
ThreadsPerChild 128
ThreadLimit 128
ServerLimit 16
</IfModule>
# Assume no memory leaks at all
MaxRequestsPerChild 20,000



Web Server 调优 - JBoss 调优

Mod-jk worker 调优



JBoss AJP Connector



Tomcat APR 设定



秒杀静态页面优化

  1. 图片合并:

  • 8张图片合并为 1张,CSS 偏移展示。

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

  • 减少发送 Cookies 的量。



  1. HTML内容压缩

  2. 图片压缩:图片 Bytes < 长 X 宽 / 2250

  3. HTML Header Cache-Control 设置

  4. CSS, JS 精简

* CSS, JS 精简到极致,部分直接写在页面中,减少 HTTP 请求次数。



下单页面优化

数据库操作:全部砍掉。

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



秒杀流程精简

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

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



采用内存缓存

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

交易系统性能优化

  • 交易系统优化目标

  • 关闭 KeepAlive(分析交易系统 accesslog,用户在短时间内连续点击概率很低)

  • JVM 优化

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

  • 消灭 Top 10 Bottlenecks

☞ Velocity 参数调优

☞ 采用 DBCP1.4 替换 C3P0

☞ Offer 产品参数的 XML 解析



二跳页面的优化

xxx.com 其它页面

  • 前端优化:Yslow 规则调优。(减少 HTTP 请求,合并 JS,CSS,图片,充分利用浏览器缓存。)

  • 图片压缩

  • 避免发送 Cookies



交易系统优化

  • 普通订单管理列表和 XXX 秒杀订单管理列表分离。

  • 禁止用模糊查询功能。



应急预案

  • 域名分离,独立域名,不影响xxx原有业务。

☞ Style 集群: style.xxx.china.xxx.com

☞ 图片服务器集群:img.xxx.china.xxx.com

☞ 静态页面集群: page.xxx.china.xxx.com

☞ 出问题直接把 xxx 相关域名卡掉,所有请求跳到万能出错页面。

  • 机动服务器10台,备用。

  • 拆东墙补西墙战略:5天时间来不及采购服务器,因此 SA 待命,随时准备将非核心应用集群的冗余服务器下线,加入到秒杀集群。

  • 壁虎断尾策略(所有办法均失效的情况下,例如流量耗尽。)

☞ 非核心应用集群统统停止服务,如咨询,论坛,博客等社区系统。

☞ 保住首页,Offer Detai,旺铺页面等核心应用的可能性。

  • 万能出错页面:秒杀活动已经结束。

☞ 任何出错都 302 跳转到此页面

☞ 位于另外集群。

  • 万幸:最终所有的预案都没有用上。

描述活动结果

  • 88 小时秒杀,坚守阵地,大获成功。

  • 秒杀还是被秒杀?终于有了答案。

  • 三道阀门设计非常有效,拦住了秒杀器。

改进一:采用更轻量 / 快速的服务器 (1)

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



Lighttpd 1.5 vs Apache 2.2.4

小页面性能 (100K)



http_load -verbose -timeout 40 -parallel 100 -fetches 500 http-load.10M.urls-100M



大页面性能(10M)

性能关键:Web Server的高性能 I/O

改进一:采用更轻量 / 快速的服务器 (2)

改进二:前端优化自动化

  • xxx服务器响应时间 < 150ms, 但Offer Detail 页面用户等待时间 5s,大部分时间耗在路上(资源请求和网络传输)。

  • 图片自动压缩(CMS自动压缩)。

  • Cookies 服务化(控制Cookies的大小)。

  • XXX 前端延迟加载框架 SmartLoad (只加载首屏数据)。

  • Google mod_pagespeed module: 自动压缩图片,静态资源,智能浏览器缓存技术。

  • Google Diffable (增量下载静态资源技术)。



改进三:架设镜像站组建山寨 CDN

xxx 青岛镜像站项目





改进四:采用反向代理 加速核心页面

在 Offer 集群前部署 Squid 反向代理集群。





改进五:海量数据的透明垂直切分

xxx 性能优化领域立项中



淘宝下单高峰在上午10点钟左右。看来很多人上班第一件事情,就是上淘宝。



宅米网性能优化实践

  • 一、性能测试

  • 二、架构优化

  • 三、H5响应压缩优化

  • 四、SQL 优化

  • 五、数据库连接池优化

  • 六、缓存优化

  • 七、订单数据冷热分离

  • 八、系统性能监控



搜索引擎



互联网搜索引擎整体架构

爬虫系统架构



爬虫禁止协议



文档矩阵与倒排索引



倒排索引



带词频的倒排索引

带词频与位置的倒排索引

Lucene 架构

Lucene 倒排索引

Lucene 索引文件准实时更新

索引有更新,就需要重新全量创建一个索引来替换原来的索引。这种方式在数据流很大时效率很低,并且由于创建一次索引的成本很高,性能也很差。



Lucene 中引入了段的概念,将一个索引文件拆分为多个子文件,每个子文件叫做段。每个段都是一个独立的可被搜索的数据集,索引的修改针对段进行操作。

  • 新增:当有新的数据需要创建索引时,原来的段不变,选择新建一个段来存储新增的数据。

  • 删除:当需要删除数据时,在索引文件新增一个 .del 的文件,用来专门存储被删除的数据ID。当查询时,被删除的数据还是可以被查到的,只是在进行文档链表合并时,才把已经删除的数据过滤掉。被删除的数据再进行段合并时才会被真正被移除。

  • 更新:更新的操作其实就是删除和新增的组合,现在 .del 的文件中记录旧数据,再在新段中添加一条更新后的数据。



为了控制索引里段的数量,我们必须定期进行段合并操作。



Lucene 缺点:不支持分布式。



Elastic Search 架构

Elastic Search 是支持分布式的搜索引擎。因为其速度快,收到很多公司的热捧,发展前景很好。



  • 索引分片,实现分布式

  • 索引备份,实现高可用。

  • API更简单、更高级

Elastic Search 分片预分配与集群扩容

PUT /my_index
{
"settings": {
"number_of_shards": 2,
"number_of_replicas": 0
}
}





总结

问题的洞察力才是做架构师的关键。



发布于: 2020 年 08 月 06 日 阅读数: 66
用户头像

John(易筋)

关注

问渠那得清如许?为有源头活水来 2018.07.17 加入

工作10+年,架构师,曾经阿里巴巴资深无线开发,汇丰银行架构师/专家。开发过日活过亿的淘宝Taobao App,擅长架构、算法、数据结构、设计模式、iOS、Java Spring Boot。易筋为阿里巴巴花名。

评论

发布
暂无评论
极客大学架构师训练营 秒杀 爬虫 搜索引擎 Lucene Elastic Search 第18课 听课总结