说明

讲师：李智慧

架构师要站顶层高度思考问题：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 30KeepAlice OnMaxKeepAliveRequests 1000KeepAliveTimeout 30
<IfModule worker.c>	StartServers	5	MaxClients		1024	MinSpareThreads	25	MaxSpareThreads	64	ThreadsPerChild	128	ThreadLimit		128	ServerLimit		16</IfModule>
# Assume no memory leaks at allMaxRequestsPerChild	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	}}

总结

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