1. 大型网站架构演化
1.1 大型网站软件系统的特点
大型互联网应用系统的特点
-高并发，大流量
-高可用
-海量数据
-用户分布广泛，网络情况复杂
-完全环境恶劣
-需求快速变更，发布频繁
-渐进式发展
1.2 大型网站架构演化发展历程
1） 初始阶段
举例来说： 操作系统Linux, 开发语言： PHP, Web服务器： Apache, 数据库： MySQL
2）应用服务和数据服务分离
改进： 网站的并发处理能力， 数据存储空间
挑战：数据库压力大导致访问延迟
3）使用缓存改善网站性能
缓存在应用服务器上的本地缓存
缓存在专门的分布式缓存服务器上的远程缓存
挑战：
单一应用服务器能够处理的请求连接有限
4）使用应用服务器集群改善网站的并发处理能力
5) 数据库读写分离
配置两台数据库主从关系
应用程序在写数据的时候，访问主数据库，主数据库通过从复制机将数据同步到从数据库。
6）使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，CDN部署在网站提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，则直接返回给用户。
7）使用分布式文件系统和分布式数据库系统
网站常用的数据库拆分手段是业务分库。
8）使用NoSQL和搜索引擎
9）业务拆分
将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
10）分布式服务
将共用的业务提取出来，独立部署。
1.3 大型网站架构演化的价值观
关注网站为用户提供什么价值。关注能做什么，而不在于它是怎么做的。
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量是网站业务的发展
1.4 当中架构设计误区
1） 一味追随大公司的解决方案
2） 为了技术而技术
3） 企图用技术解决所有问题
2. 大型网站架构模式
2.1 网站架构模式
1） 分层
将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
一般分为：
应用层：负责具体业务和视图展示，如网站首页及搜索输入和结果展示， 还可细分为视图层和业务逻辑层
服务层：为应用层提供服务支持，如用户管理服务； 还可细分为数据接口层和逻辑处理层
数据层：提供数据存储访问服务，如数据库、缓存、文件、
禁止跨层次调用和逆向调用
2）分割
在纵向方面对软件进行切分
将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。4
3）分布式
问题：
a. 服务调用通过网络，对性能造成影响
b.服务器多， 宕机概率增大
c.数据一致性比较困难，分布式事务的处理
d. 开发管理维护困难
常见的分布式方案：
分布式应用和服务
分布式静态资源
分布式数据和存储：NoSQL
分布式计算： Hadoop , MapReduce
分布式配置，分布式锁，分布式文件系统
4）集群
5）缓存
CDN： 缓存网站的一些静态资源
反向代理
本地缓存
分布式缓存
缓存前提条件：
a. 数据访问热点不均衡
b. 数据某个时间段内有效，不会很快过期
6) 异步
单一服务器通过多线程共享内存队列的方式实现异步，在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作是内存队列的分布式部署。
异步消息队列的特征：
a. 提供系统可用性
b. 加快网站响应速度
c. 消除并发访问高峰
7）冗余
数据冗余备份，冷备份与主从热备份
服务器集群
8）自动化
发布运维自动化
-自动化代码管理
-自动化测试
-自动化安全检测
-自动化部署
-自动化监控
-自动化报警
-自动化失效转移
-自动化失效恢复
-自动化降级
-自动化分配资源
9）安全
密码，手机验证码； 验证码； 过滤，风险控制
2.2 架构模式在新浪微博的应用
分为三个层次
最下层是基础服务层，提供数据库、缓存、存储、搜索等数据服务，和其他一些基础技术服务，这些服务支撑了海量数据和高并发访问， 是整个系统的技术基础
中间是平台服务和应用服务层，这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成业务基础
最上层是API和业务层，各种客户端和第三方应用，通过调用API集成到系统，组成一个生态系统。
3. 大型网站核心架构要素
架构 - 最高层次的规划，难以改变的决定
软件架构 - 有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计
需要考虑要素： 系统功能需求， 性能，可用性，伸缩性，扩展性和安全性
3.1 性能
性能优化手段
在浏览器端-通过浏览器缓存、页面压缩、合理布局页面、减少Cookie传输等
使用CDN,将网站静态内容分发至离用户最近的网络服务商机房，使用户通过最短访问路径获取数据。在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力。
在应用服务器端-使用服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。
通过异步操作将用户请求发送至消息队列等待后续任务处理， 当前请求直接返回响应给用户
将多台应用服务器组成一个集群共同对外服务，提高整理处理能力，改善性能。
在代码层面，通过使用多线程，改善内存管理等手段优化性能。
在数据库服务器端，- 索引，缓存，SQL优化。 NoSQL数据库优化数据模型、存储结构，伸缩特性
衡量网站的性能指标： 响应时间， 系统性能计数器等。高并发访问
３.２ 可用性
＞ ９９９．９９％
高可用设计的目标是当服务器宕机的时候， 服务或者应用依然可用。
网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问， 数据存储在多台服务器上相互备份。
多台应用服务器通过负载均衡组成集群，任何一台宕机，把请求切换到其他服务器，前提条件是应用服务器不能保存请求的会话信息。
存储服务器，实时备份。
除了运行环境， 软件开发过程的质量保证， 通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大。
３.３ 伸缩性
所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。
应用服务器集群，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
缓存服务器集群，加入新的服务可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。虽然可以通过数据库重新加载，但如果应用严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
关系数据库的集群伸缩方案必须在数据库之外实现，通过路由分区等手段将部署有多个服务器的数据库组成一个集群。
3.4 扩展性
网站的扩展性架构直接关注网站的功能。
主要手段是事件驱动架构和分布式服务。
事件驱动架构通常利用消息队列实现。
分布式服务则是将业务和可复用分离开来，通过分布式服务框架调用。
3.5 安全性
4. 瞬时响应-网站的高性能架构
网站性能指标：
客观指标：响应时间、吞吐量 等
主观指标：用户的感受
4.1 网站性能测试
4.1.1 不同视角下的网站性能
1.用户视角的网站性能
计算机性能差异、浏览器解析HTML速度、不同网络运营商提供的互联网宽带服务都会产生影响。
前端优化手段：优化页面HTML样式、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段。
2. 开发人员视角的网站性能
响应时间、系统吞吐量、并发处理能力、系统稳定性。
优化手段： 缓存加速数据读取，集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善性能。
3. 运维人员视角的网站性能
关注基础设施性能和资源利用率， 如网络运营商的带宽能力、服务器硬件配置、数据中心网络架构、服务器和网络带宽的资源利用率。
优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用。
4.1.2 性能测试指标
从开发和测试人员的角度：
1.响应时间
发出请求到最后响应数据所需要的时间
常用系统操作响应时间表：
重复请求的方式进行测试。
2. 并发数
网站并发用户数，同时提交请求的用户数据数目。
通过多线程模拟并发用户的方法来测试。
3.吞吐量
单位时间内系统处理的请求数量，体现系统的整体处理能力。
衡量指标：
请求数/秒； 页面数/秒； 访问人数/天； 处理的业务数/小时
TPS-每秒事务数， HPS-每秒HTTP请求数，QPS-每秒查询数。
场景模拟：
在系统并发数由小逐渐增大的过程中， 系统资源消耗逐渐增大，系统吞吐量先是逐渐增加，达到一个极限后， 随着并发数的增加反而下降，达到系统崩溃点后，系统资源耗尽，吞吐量为0.
在此过程中，响应时间则是先保持小幅上升，到达吞吐量极限后，快速上升，到达系统崩溃点后，系统失去响应。
形象比喻一下：
吞吐量是每天高速收费站通过的车辆数目，并发是正在行驶的车辆数目，响应时间是车速。
网站性能优化的目的，除了改善用户体验的响应时间，还要尽量提高系统吞吐量，最大限度利用服务器资源。
4.性能计数器
是描述服务器或操作系统的一些数据指标， 包括：
System Load; 对象与线程数； 内存使用； CPU使用； 磁盘与网络I/O等指标
4.1.3 性能测试方法
性能测试； 负载测试 ； 压力测试； 稳定性测试
4.1.4 性能测试报告
一个例子：
4.1.5 性能优化策略
1.性能分析
2.性能优化： Web前段性能优化， 应用服务器性能优化， 存储服务器性能优化
4.2 Web前端性能优化
Web前端功能： 浏览器加载；网站视图模型；图片服务； CDN服务等
主要优化手段： 优化浏览器访问；使用反向代理、CDN等
4.2.1 浏览器访问优化
1. 减少http请求
HTTP协议是无状态的应用层协议，每次HTTP请求都要建立通信链路、进行数据传输
在服务端， 每个HTTP都需要启动独立的线程去处理。
2.使用浏览器缓存
设置HTTP头中的Cache-Control和Expires.
更新静态资源时，采取批量更新的方法。
3.启用压缩
Gzip 压缩。 压缩对服务器和浏览器会产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑。
4. CSS放在页面 最上面， JavaScript放在页面最下面。
浏览器会在下载完全部CSS之后才对整个页面进行渲染。
浏览器再加载JavaScript后立即执行，有可能阻塞整个页面，造成页面显示缓慢。但如果页面解析时就需要用到Javascript,放在底部就不合适了。
5.减少Cookie传输
可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie,减少Cookie传输的次数。
4.2.2 CDN加速
CDN- Content Distribute Network,内容分发网络。
本质仍然是一个缓存，将数据缓存在离用户最近的地方。
CDN能够缓存的一般是静态资源。
4.2.3 反向代理
传统代理服务器位于浏览器一侧，反向代理服务器位于网站机房一侧。
作用： 保护网站， 通过配置缓存加速Web请求，负载均衡。
4.3 应用服务器性能优化
4.3.1 分布式缓存
网站性能优化第一定律： 优先考虑使用缓存优化性能。
合理使用， 不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。
频繁修改的数据、没有热点的访问等状况不适合使用缓存。
缓存预热： 热点数据是计算出来的，新启动的缓存系统没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，在缓存系统启动时就把热点数据加载好。
缓存穿透：将不存在的数据也缓存起来（value值为null）
分布式缓存架构
在多个服务器组成的集群中， 以集群方式提供缓存服务。
一种是以JBoss Cache为代表的需要更新同步的分布式缓存。
一种是以Memcache为代表的不相互通信的分布式缓存。
JBoss Cache, 将应用程序和缓存部署在同一台服务器上，应用程序从本地快速获取缓存数据。
缺点: 受限于单一服务器的内存空间，当集群规模很大时，缓存更新信息需同步到集群所有机器，代价惊人。
多用于企业应用系统中， 大型网站较少使用。
大型网站缓存量一般很庞大， 需要数TB的内存作缓存。
Memcache采用一种集中式的缓存集群管理， 也称作互不通信的分布式架构方式。
缓存系统部署在一组专门的服务器上， 应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模很容易实现扩容， 具有良好的可伸缩性。
Memcached内存管理方式：
4.3.2 异步操作
使用消息队列调用异步化， 可改善网站的扩展性 和网站系统的性能。
4.3.3 使用集群
负载均衡技术
4.3.4 代码优化手段
1. 多线程
解决线程安全的主要手段：
1） 将对象设计为无状态对象。对象本身不存储状态信息（对象无成员变量，或者成员变量也是无状态对象）。比如： Servlet对象，贫血模型对象。不过从面向对象设计角度看，无状态对象是一种不良设计。
2）使用局部对象。
3） 并发访问资源时使用锁。锁会导致现场同步执行，可能会对系统性能产生严重影响。
2. 资源复用
减少开销很大的资源的创建和销毁，比如数据库连接、网络通信连接、线程、复杂对象等。从变成角度，资源复用主要有两种模式：单例和对象池。
3. 数据结构
Time33 算法- Hash散列算法， 对字符串逐字符迭代乘以33， 减少Hash表的冲突。
Time33 虽然可以很好地解决冲突，但是有可能相似字符串的HashCode也比较接近，一个可行的方案是对字符串取信息指纹，再对信息指纹求HashCode.
4.垃圾回收
减少Full GC
4.4 存储性能优化
4.4.1 机械硬盘 VS. 固态硬盘
4.4.2 B+树 VS. LSM树
传统关系型数据库使用B+树对数据排序存储，加快数据检索速度，保证数据在不断更新、插入、删除后依旧有序。B+树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中，从根节点开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存后继续查找，直到找到所需数据。
许多NoSQL产品采用LSM树作为主要数据结构：
4.4.3 RAID vs. HDFS
RAID-廉价磁盘冗余阵列。实现数据在多块磁盘上的并发读写和数据备份。
HDFS - Hadoop 分布式文件系统。
HDFS以块（Block）为单位管理文件内容， 一个文件被分割成若干个Block,当应用程序写文件时，每写完一个Block,HDFS就将其自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台服务器宕机，数据依然可以访问，相当于实现了RAID1的数据复制功能。
1.1 大型网站软件系统的特点
大型互联网应用系统的特点
-高并发，大流量
-高可用
-海量数据
-用户分布广泛，网络情况复杂
-完全环境恶劣
-需求快速变更，发布频繁
-渐进式发展
1.2 大型网站架构演化发展历程
1） 初始阶段
举例来说： 操作系统Linux, 开发语言： PHP, Web服务器： Apache, 数据库： MySQL
2）应用服务和数据服务分离
改进： 网站的并发处理能力， 数据存储空间
挑战：数据库压力大导致访问延迟
3）使用缓存改善网站性能
缓存在应用服务器上的本地缓存
缓存在专门的分布式缓存服务器上的远程缓存
挑战：
单一应用服务器能够处理的请求连接有限
4）使用应用服务器集群改善网站的并发处理能力
5) 数据库读写分离
配置两台数据库主从关系
应用程序在写数据的时候，访问主数据库，主数据库通过从复制机将数据同步到从数据库。
6）使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，CDN部署在网站提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，则直接返回给用户。
7）使用分布式文件系统和分布式数据库系统
网站常用的数据库拆分手段是业务分库。
8）使用NoSQL和搜索引擎
9）业务拆分
将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
10）分布式服务
将共用的业务提取出来，独立部署。
1.3 大型网站架构演化的价值观
关注网站为用户提供什么价值。关注能做什么，而不在于它是怎么做的。
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量是网站业务的发展
1.4 当中架构设计误区
1） 一味追随大公司的解决方案
2） 为了技术而技术
3） 企图用技术解决所有问题
2. 大型网站架构模式
2.1 网站架构模式
1） 分层
将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
一般分为：
应用层：负责具体业务和视图展示，如网站首页及搜索输入和结果展示， 还可细分为视图层和业务逻辑层
服务层：为应用层提供服务支持，如用户管理服务； 还可细分为数据接口层和逻辑处理层
数据层：提供数据存储访问服务，如数据库、缓存、文件、
禁止跨层次调用和逆向调用
2）分割
在纵向方面对软件进行切分
将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。4
3）分布式
问题：
a. 服务调用通过网络，对性能造成影响
b.服务器多， 宕机概率增大
c.数据一致性比较困难，分布式事务的处理
d. 开发管理维护困难
常见的分布式方案：
分布式应用和服务
分布式静态资源
分布式数据和存储：NoSQL
分布式计算： Hadoop , MapReduce
分布式配置，分布式锁，分布式文件系统
4）集群
5）缓存
CDN： 缓存网站的一些静态资源
反向代理
本地缓存
分布式缓存
缓存前提条件：
a. 数据访问热点不均衡
b. 数据某个时间段内有效，不会很快过期
6) 异步
单一服务器通过多线程共享内存队列的方式实现异步，在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作是内存队列的分布式部署。
异步消息队列的特征：
a. 提供系统可用性
b. 加快网站响应速度
c. 消除并发访问高峰
7）冗余
数据冗余备份，冷备份与主从热备份
服务器集群
8）自动化
发布运维自动化
-自动化代码管理
-自动化测试
-自动化安全检测
-自动化部署
-自动化监控
-自动化报警
-自动化失效转移
-自动化失效恢复
-自动化降级
-自动化分配资源
9）安全
密码，手机验证码； 验证码； 过滤，风险控制
2.2 架构模式在新浪微博的应用
分为三个层次
最下层是基础服务层，提供数据库、缓存、存储、搜索等数据服务，和其他一些基础技术服务，这些服务支撑了海量数据和高并发访问， 是整个系统的技术基础
中间是平台服务和应用服务层，这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成业务基础
最上层是API和业务层，各种客户端和第三方应用，通过调用API集成到系统，组成一个生态系统。
3. 大型网站核心架构要素
架构 - 最高层次的规划，难以改变的决定
软件架构 - 有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计
需要考虑要素： 系统功能需求， 性能，可用性，伸缩性，扩展性和安全性
3.1 性能
性能优化手段
在浏览器端-通过浏览器缓存、页面压缩、合理布局页面、减少Cookie传输等
使用CDN,将网站静态内容分发至离用户最近的网络服务商机房，使用户通过最短访问路径获取数据。在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力。
在应用服务器端-使用服务器本地缓存和分布式缓存，通过缓存在内存中的热点数据处理用户请求，加快请求处理过程，减轻数据库负载压力。
通过异步操作将用户请求发送至消息队列等待后续任务处理， 当前请求直接返回响应给用户
将多台应用服务器组成一个集群共同对外服务，提高整理处理能力，改善性能。
在代码层面，通过使用多线程，改善内存管理等手段优化性能。
在数据库服务器端，- 索引，缓存，SQL优化。 NoSQL数据库优化数据模型、存储结构，伸缩特性
衡量网站的性能指标： 响应时间， 系统性能计数器等。高并发访问
３.２ 可用性
＞ ９９９．９９％
高可用设计的目标是当服务器宕机的时候， 服务或者应用依然可用。
网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问， 数据存储在多台服务器上相互备份。
多台应用服务器通过负载均衡组成集群，任何一台宕机，把请求切换到其他服务器，前提条件是应用服务器不能保存请求的会话信息。
存储服务器，实时备份。
除了运行环境， 软件开发过程的质量保证， 通过预发布验证、自动化测试、自动化发布、灰度发布等手段，减少将故障引入线上环境的可能，避免故障范围扩大。
３.３ 伸缩性
所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。
应用服务器集群，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。
缓存服务器集群，加入新的服务可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。虽然可以通过数据库重新加载，但如果应用严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。
关系数据库的集群伸缩方案必须在数据库之外实现，通过路由分区等手段将部署有多个服务器的数据库组成一个集群。
3.4 扩展性
网站的扩展性架构直接关注网站的功能。
主要手段是事件驱动架构和分布式服务。
事件驱动架构通常利用消息队列实现。
分布式服务则是将业务和可复用分离开来，通过分布式服务框架调用。
3.5 安全性
4. 瞬时响应-网站的高性能架构
网站性能指标：
客观指标：响应时间、吞吐量 等
主观指标：用户的感受
4.1 网站性能测试
4.1.1 不同视角下的网站性能
1.用户视角的网站性能
计算机性能差异、浏览器解析HTML速度、不同网络运营商提供的互联网宽带服务都会产生影响。
前端优化手段：优化页面HTML样式、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段。
2. 开发人员视角的网站性能
响应时间、系统吞吐量、并发处理能力、系统稳定性。
优化手段： 缓存加速数据读取，集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善性能。
3. 运维人员视角的网站性能
关注基础设施性能和资源利用率， 如网络运营商的带宽能力、服务器硬件配置、数据中心网络架构、服务器和网络带宽的资源利用率。
优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用。
4.1.2 性能测试指标
从开发和测试人员的角度：
1.响应时间
发出请求到最后响应数据所需要的时间
常用系统操作响应时间表：
重复请求的方式进行测试。
2. 并发数
网站并发用户数，同时提交请求的用户数据数目。
通过多线程模拟并发用户的方法来测试。
3.吞吐量
单位时间内系统处理的请求数量，体现系统的整体处理能力。
衡量指标：
请求数/秒； 页面数/秒； 访问人数/天； 处理的业务数/小时
TPS-每秒事务数， HPS-每秒HTTP请求数，QPS-每秒查询数。
场景模拟：
在系统并发数由小逐渐增大的过程中， 系统资源消耗逐渐增大，系统吞吐量先是逐渐增加，达到一个极限后， 随着并发数的增加反而下降，达到系统崩溃点后，系统资源耗尽，吞吐量为0.
在此过程中，响应时间则是先保持小幅上升，到达吞吐量极限后，快速上升，到达系统崩溃点后，系统失去响应。
形象比喻一下：
吞吐量是每天高速收费站通过的车辆数目，并发是正在行驶的车辆数目，响应时间是车速。
网站性能优化的目的，除了改善用户体验的响应时间，还要尽量提高系统吞吐量，最大限度利用服务器资源。
4.性能计数器
是描述服务器或操作系统的一些数据指标， 包括：
System Load; 对象与线程数； 内存使用； CPU使用； 磁盘与网络I/O等指标
4.1.3 性能测试方法
性能测试； 负载测试 ； 压力测试； 稳定性测试
4.1.4 性能测试报告
一个例子：
4.1.5 性能优化策略
1.性能分析
2.性能优化： Web前段性能优化， 应用服务器性能优化， 存储服务器性能优化
4.2 Web前端性能优化
Web前端功能： 浏览器加载；网站视图模型；图片服务； CDN服务等
主要优化手段： 优化浏览器访问；使用反向代理、CDN等
4.2.1 浏览器访问优化
1. 减少http请求
HTTP协议是无状态的应用层协议，每次HTTP请求都要建立通信链路、进行数据传输
在服务端， 每个HTTP都需要启动独立的线程去处理。
2.使用浏览器缓存
设置HTTP头中的Cache-Control和Expires.
更新静态资源时，采取批量更新的方法。
3.启用压缩
Gzip 压缩。 压缩对服务器和浏览器会产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑。
4. CSS放在页面 最上面， JavaScript放在页面最下面。
浏览器会在下载完全部CSS之后才对整个页面进行渲染。
浏览器再加载JavaScript后立即执行，有可能阻塞整个页面，造成页面显示缓慢。但如果页面解析时就需要用到Javascript,放在底部就不合适了。
5.减少Cookie传输
可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie,减少Cookie传输的次数。
4.2.2 CDN加速
CDN- Content Distribute Network,内容分发网络。
本质仍然是一个缓存，将数据缓存在离用户最近的地方。
CDN能够缓存的一般是静态资源。
4.2.3 反向代理
传统代理服务器位于浏览器一侧，反向代理服务器位于网站机房一侧。
作用： 保护网站， 通过配置缓存加速Web请求，负载均衡。
4.3 应用服务器性能优化
4.3.1 分布式缓存
网站性能优化第一定律： 优先考虑使用缓存优化性能。
合理使用， 不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。
频繁修改的数据、没有热点的访问等状况不适合使用缓存。
缓存预热： 热点数据是计算出来的，新启动的缓存系统没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，在缓存系统启动时就把热点数据加载好。
缓存穿透：将不存在的数据也缓存起来（value值为null）
分布式缓存架构
在多个服务器组成的集群中， 以集群方式提供缓存服务。
一种是以JBoss Cache为代表的需要更新同步的分布式缓存。
一种是以Memcache为代表的不相互通信的分布式缓存。
JBoss Cache, 将应用程序和缓存部署在同一台服务器上，应用程序从本地快速获取缓存数据。
缺点: 受限于单一服务器的内存空间，当集群规模很大时，缓存更新信息需同步到集群所有机器，代价惊人。
多用于企业应用系统中， 大型网站较少使用。
大型网站缓存量一般很庞大， 需要数TB的内存作缓存。
Memcache采用一种集中式的缓存集群管理， 也称作互不通信的分布式架构方式。
缓存系统部署在一组专门的服务器上， 应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模很容易实现扩容， 具有良好的可伸缩性。
Memcached内存管理方式：
4.3.2 异步操作
使用消息队列调用异步化， 可改善网站的扩展性 和网站系统的性能。
4.3.3 使用集群
负载均衡技术
4.3.4 代码优化手段
1. 多线程
解决线程安全的主要手段：
1） 将对象设计为无状态对象。对象本身不存储状态信息（对象无成员变量，或者成员变量也是无状态对象）。比如： Servlet对象，贫血模型对象。不过从面向对象设计角度看，无状态对象是一种不良设计。
2）使用局部对象。
3） 并发访问资源时使用锁。锁会导致现场同步执行，可能会对系统性能产生严重影响。
2. 资源复用
减少开销很大的资源的创建和销毁，比如数据库连接、网络通信连接、线程、复杂对象等。从变成角度，资源复用主要有两种模式：单例和对象池。
3. 数据结构
Time33 算法- Hash散列算法， 对字符串逐字符迭代乘以33， 减少Hash表的冲突。
Time33 虽然可以很好地解决冲突，但是有可能相似字符串的HashCode也比较接近，一个可行的方案是对字符串取信息指纹，再对信息指纹求HashCode.
4.垃圾回收
减少Full GC
4.4 存储性能优化
4.4.1 机械硬盘 VS. 固态硬盘
4.4.2 B+树 VS. LSM树
传统关系型数据库使用B+树对数据排序存储，加快数据检索速度，保证数据在不断更新、插入、删除后依旧有序。B+树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中，从根节点开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存后继续查找，直到找到所需数据。
许多NoSQL产品采用LSM树作为主要数据结构：
4.4.3 RAID vs. HDFS
RAID-廉价磁盘冗余阵列。实现数据在多块磁盘上的并发读写和数据备份。
HDFS - Hadoop 分布式文件系统。
HDFS以块（Block）为单位管理文件内容， 一个文件被分割成若干个Block,当应用程序写文件时，每写完一个Block,HDFS就将其自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台服务器宕机，数据依然可以访问，相当于实现了RAID1的数据复制功能。
当对文件进行处理计算时，通过MapReduce并发计算任务框架，可以启动多个计算子任务(MapReduce Task), 同时读取文件的多个Block,并发处理，相当于实现了RAID0的并发访问功能。
