大型网站技术架构-4 瞬时响应：网站的高性能架构

读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》

---

4 瞬时响应：网站的高性能架构

网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。

4.1 网站性能测试

4.1.1 不同视角下的网站性能

1. 用户视角的网站性能
   从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。
   在实践中，使用一些前端架构优化手段，通过优化页面HTML式样、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段，使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度地改善用户视角下的网站性能。

2. 开发人员视角的网站性能
   主要的优化手段有使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能。

3. 运维人员视角的网站性能
   主要优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。

4.1.2 性能测试指标

1. 响应时间
   指应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”。

2. 并发数
   指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于网站而言，并发数即网站并发用户数，指同时提交请求的用户数目。
   网站系统用户数＞＞网站在线用户数＞＞网站并发用户数
   网站技术准备不充分导致，也有可能是运营人员错误地评估并发用户数导致。
   两次请求之间加入一个随机等待时间，这个时间被称作思考时间。

3. 吞吐量
   指单位时间内系统处理的请求数量，体现系统的整体处理能力。
   在系统并发数由小逐渐增大的过程中（这个过程也伴随着服务器系统资源消耗逐渐增大），系统吞吐量先是逐渐增加，达到一个极限后，随着并发数的增加反而下降，达到系统崩溃点后，系统资源耗尽，吞吐量为零。
   网站性能优化的目的，除了改善用户体验的响应时间，还要尽量提高系统吞吐量，最大限度利用服务器资源。

4. 性能计数器
   它是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

4.1.3 性能测试方法

性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。

4.1.5 性能优化策略

分而治之，逐步优化。

1. 性能分析
   排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。

2. 性能优化
   定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类。

4.2 Web前端性能优化

一般说来Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN等。

4.2.1 浏览器访问优化

1. 减少http请求
   减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。

2. 使用浏览器缓存
   使用浏览器缓存策略的网站在更新静态资源时，应采用批量更新的方法，比如需要更新10个图标文件，不宜把10个文件一次全部更新，而是应一个文件一个文件逐步更新，并有一定的间隔时间，以免用户浏览器突然大量缓存失效，集中更新缓存，造成服务器负载骤增、网络堵塞的情况。

3. 启用压缩

4. CSS放在页面最上面、JavaScript放在页面最下面

5. 减少Cookie传输

4.2.2 CDN加速

CDN（Content Distribute Network，内容分发网络）的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户以最快速度获取数据，即所谓网络访问第一跳

4.2.3 反向代理

传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。
2016-12-23
和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网络攻击之间建立了一个屏障。

4.3 应用服务器性能优化

应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开发最复杂，变化最多的地方，优化手段主要有缓存、集群、异步等。

4.3.1　分布式缓存

回顾网站架构演化历程，当网站遇到性能瓶颈时，第一个想到的解决方案就是使用缓存。

网站性能优化第一定律：优先考虑使用缓存优化性能。

1. 缓存的基本原理
   缓存指将数据存储在相对较高访问速度的存储介质中，以供系统处理。一方面缓存访问速度快，可以减少数据访问的时间，另一方面如果缓存的数据是经过计算处理得到的，那么被缓存的数据无需重复计算即可直接使用，因此缓存还起到减少计算时间的作用。
   缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。
   网站数据访问通常遵循二八定律，即80%的访问落在20%的数据上，因此利用Hash表和内存的高速访问特性，将这20%的数据缓存起来，可很好地改善系统性能，提高数据读取速度，降低存储访问压力。

2. 合理使用缓存
   频繁修改的数据
   一般说来，数据的读写比在2：1以上，即写入一次缓存，在数据更新前至少读取两次，缓存才有意义。
   没有热点的访问
   如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问并没有集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了。
   数据不一致与脏读
   数据更新时立即更新缓存，不过这也会带来更多系统开销和事务一致性的问题。
   缓存可用性
   缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。
   通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机的时候，只有部分缓存数据丢失，重新从数据库加载这部分数据不会对数据库产生很大影响。
   产品在设计之初就需要一个明确的定位：什么是产品要实现的功能，什么不是产品提供的特性。在产品漫长的生命周期中，会有形形色色的困难和诱惑来改变产品的发展方向，左右摇摆、什么都想做的产品，最后有可能成为一个失去生命力的四不像。
   缓存预热
   新启动的缓存系统如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫作缓存预热（warmup）。
   缓存穿透
   一个简单的对策是将不存在的数据也缓存起来（其value值为null）。

3. 分布式缓存架构
   分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其架构方式有两种，一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Memcached为代表的不互相通信的分布式缓存。
   JBoss Cache的分布式缓存在集群中所有服务器中保存相同的缓存数据，当某台服务器有缓存数据更新的时候，会通知集群中其他机器更新缓存数据或清除缓存数
   这种方案更多见于企业应用系统中，而很少在大型网站使用。
   大型网站需要缓存的数据量一般都很庞大，可能会需要数TB的内存做缓存
   Memcached采用一种集中式的缓存集群管理，也被称作互不通信的分布式架构方式。
   缓存服务器之间不通信，缓存集群的规模可以很容易地实现扩容，具有良好的可伸缩性。

4. Memcached
   Memcached曾一度是网站分布式缓存的代名词，被大量网站使用。其简单的设计、优异的性能、互不通信的服务器集群、海量数据可伸缩的架构令网站架构师们趋之若鹜。
   简单的通信协议
   Memcached使用TCP协议（UDP也支持）通信，其序列化协议则是一套基于文本的自定义协议，非常简单
   丰富的客户端程序
   在混合使用多种编程语言的网站，Memcached更是如鱼得水。
   高性能的网络通信
   高效的内存管理
   Memcached使用了一个非常简单的办法——固定空间分配
   当然这种方式也会带来内存浪费的问题。数据只能存入一个比它大的chunk里，而一个chunk只能存一个数据，其他空间被浪费了。
   互不通信的服务器集群架构
   而其客户端路由算法一致性Hash更成为数据存储伸缩性架构设计的经典范式
   正是集群内服务器互不通信使得集群可以做到几乎无限制的线性伸缩
   Memcached由于其简单、稳定、专注的特点，仍然在分布式缓存领域占据着重要地位。

4.3.2　异步操作

使用消息队列将调用异步化，可改善网站的扩展性（参考本书第7章内容）。事实上，使用消息队列还可改善网站系统的性能

消息队列具有很好的削峰作用——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。

在使用消息队列进行业务异步处理后，需要适当修改业务流程进行配合

任何可以晚点做的事情都应该晚点再做。

4.3.3　使用集群

在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性

4.3.4　代码优化

合理优化业务代码，可以很好地改善网站性能。

1. 多线程
   由于线程比进程更轻量，更少占有系统资源，切换代价更小，所以目前主要的Web应用服务器都采用多线程的方式响应并发用户请求，因此网站开发天然就是多线程编程。
   理想的系统Load是既没有进程（线程）等待也没有CPU空闲，利用多线程IO阻塞与执行交替进行，可最大限度地利用CPU资源。
   启动线程数=［任务执行时间/（任务执行时间-IO等待时间）］×CPU内核数
   如果任务都是CPU计算型任务，那么线程数最多不超过CPU内核数，因为启动再多线程，CPU也来不及调度；相反如果是任务需要等待磁盘操作，网络响应，那么多启动线程有助于提高任务并发度，提高系统吞吐能力，改善系统性能。
   多线程编程一个需要注意的问题是线程安全问题
   缺乏经验的网站工程师最容易犯错的地方，而线程安全Bug又难以测试和重现，网站故障中，许多所谓偶然发生的“灵异事件”都和多线程并发问题有关。
   将对象设计为无状态对象
   无状态对象是指对象本身不存储状态信息
   Web开发中常用的贫血模型对象都是些无状态对象。不过从面向对象设计的角度看，无状态对象是一种不良设计。
   使用局部对象
   并发访问资源时使用锁
   多线程访问资源的时候，通过锁的方式使多线程并发操作转化为顺序操作，从而避免资源被并发修改。

2. 资源复用
   系统运行时，要尽量减少那些开销很大的系统资源的创建和销毁
   从编程角度，资源复用主要有两种模式：单例（Singleton）和对象池（Object Pool）。
   Spring的单例是Spring容器管理的单例，而不是用单例模式构造的单例
   对象池模式通过复用对象实例，减少对象创建和资源消耗。
   因此在实践中，应用程序的数据库连接基本都使用连接池（Connection Pool）的方式。

3. 数据结构
   在不同场景中合理使用恰当的数据结构，灵活组合各种数据结构改善数据读写和计算特性可极大优化程序的性能。
   目前比较好的字符串Hash散列算法有Time33算法，即对字符串逐字符迭代乘以33，求得Hash值

4. 垃圾回收
   以JVM为例，其内存主要可划分为堆（heap）和堆栈（stack）。堆栈用于存储线程上下文信息，如方法参数、局部变量等。堆则是存储对象的内存空间，对象的创建和释放、垃圾回收就在这里进行。
   应根据系统业务特点和对象生命周期，合理设置Young Generation和Old Generation大小，尽量减少Full GC。事实上，某些Web应用在整个运行期间可以做到从不进行Full GC。

4.4 存储性能优化

磁盘中存储的数据是网站最重要的资产，磁盘的可用性和容错性也至关重要。

4.4.1 机械硬盘vs.固态硬盘

机械硬盘在数据连续访问（要访问的数据存储在连续的磁盘空间上）和随机访问（要访问的数据存储在不连续的磁盘空间）时，由于移动磁头臂的次数相差巨大，性能表现差别也非常大。

SSD具有更小的功耗和更少的磁盘震动与噪声。

4.4.2 B+树vs.LSM树

为了改善数据访问特性，文件系统或数据库系统通常会对数据排序后存储，加快数据检索速度，这就需要保证数据在不断更新、插入、删除后依然有序，传统关系数据库的做法是使用B+树

目前数据库多采用两级索引的B+树，树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录（三次磁盘访问获得数据索引及行ID，然后再进行一次数据文件读操作及一次数据文件写操作）。

在LSM树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树。

4.4.3 RAIDvs.HDFS

RAID（廉价磁盘冗余阵列）技术主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。目前服务器级别的计算机都支持插入多块磁盘（8块或者更多），通过使用RAID技术，实现数据在多块磁盘上的并发读写和数据备份。

RAID1
数据在写入磁盘时，将一份数据同时写入两块磁盘，这样任何一块磁盘损坏都不会导致数据丢失，插入一块新磁盘就可以通过复制数据的方式自动修复，具有极高的可靠性。

RAID3很少在实践中使用。

RAID5和RAID3很相似，但是校验数据不是写入第N块磁盘，而是螺旋式地写入所有磁盘中。这样校验数据的修改也被平均到所有磁盘上，避免RAID3频繁写坏一块磁盘的情况。

RAID技术可以通过硬件实现，比如专用的RAID卡或者主板直接支持，也可以通过软件实现。RAID技术在传统关系数据库及文件系统中应用比较广泛，但是在大型网站比较喜欢使用的NoSQL，以及分布式文件系统中，RAID技术却遭到冷落。

HDFS配合MapReduce等并行计算框架进行大数据处理时，可以在整个集群上并发读写访问所有的磁盘，无需RAID支持。

4.5 小结

网站性能优化的主要工作是改善高并发用户访问情况下的网站响应速度。

而架构师能做到的，则是利用分布式的方案改善网站并发特性，由于分布式不可避免地会带来架构复杂、网络通信延迟等问题，所以最终设计出来的可能是B方案：缩短高并发访问响应延迟的同时，却延长了原来低并发访问时的响应延迟。架构师对这种可能性要心中有数，合理调整相关各方对性能优化的心理预期。

用户体验的快或是慢，可以通过技术手段改善，也可以通过优化交互体验改善。

技术是为业务服务的，技术选型和架构决策依赖业务规划乃至企业战略规划，离开业务发展的支撑和驱动，技术走不远，甚至还会迷路。

前沿技术总是出现在前沿业务领域。近几年，以Google为首的互联网企业领跑IT前沿技术潮流，是因为互联网企业的业务发展远超传统IT企业领域，面临更多挑战，对IT系统提出了更高的要求。

新技术的出现又会驱动企业开展新的业务。亚马逊等互联网公司利用自己的技术优势进军企业级市场，以技术驱动业务，开展云计算、SaaS等新兴IT业务，逐步蚕食IBM、HP、Oracle、微软等传统软件巨头的市场。

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls