《大型网站技术架构-核心原理与案例分析》(李智慧著)第4章-瞬时响应:网站的高性能架构(待补充)

4.1 网站性能测试
性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段
- 4.1.1 不同视角下的网站性能
  - 用户视角的网站性能
    - 关注点
      - 从用户角度，网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。
      - 用户感受到的时间，包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、用户计算机浏览器构造请求解析响应数据的时间
      - 不同计算机的性能差异，不同浏览器解析HTML速度的差异，不同网络运营商提供的互联网宽带服务的差异，这些差异最终导致用户感受到的响应延迟可能会远远大于网站服务器处理请求所需要的时间
    - 优化手段
      - 在实践中使用一些前端架构优化手段，通过优化页面HTML样式、利用浏览器端的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段，使浏览器尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构，也可以很大程度地改善用户视角下的网站性能
  - 开发人员视角的网站性能
    - 关注点
      - 开发人员关注的主要是应用程序本身及其相关子系统的性能
      - 包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等技术指标
    - 优化手段
      - 使用缓存加速数据读取
      - 使用集群提高吞吐能力
      - 使用异步消息加快请求响应及实现削锋
      - 使用代码优化手段改善程序性能
  - 运维人员视角的网站性能
    - 关注点
      - 运维人员更关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。
    - 优化手段
      - 建设优化骨干网
      - 使用高性价比定制服务器
      - 利用虚拟化技术优化资源利用
- 4.1.2 性能测试指标
  不同视角下有不同的性能标准，不同的指标有不同的性能测试指标，从开发和测试人员的视角，网站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等
  - 响应时间
    - 定义
      - 响应时间指应用执行一个操作需要的时间，包括从发出请求到收到最后响应数据所需要的时间，响应时间是系统最重要的性能指标，直观地反应了系统的"快慢"
  - 并发数
    - 定义
      - 并发数指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。
      - 对于网站而言，并发数即网站并发用户数，指同时提交请求的用户数目
    - 扩展
      - 与网站并发用户数相对应的还有网站在线用户数(当前登陆网站的用户总数)和网站系统用户数(可能访问系统的总用户数，对多数网站而言就是注册用户数)
      - 网站系统用户数、网站在线用户数和网站并发用户数的数量比较关系为: 网站系统用户数>>网站在线用户数>>网站并发用户数
      - 网站产品建设初期，产品经理和运营人员就需要规划不同发展阶段的网站系统用户数、并以此为基础，根据产品特性和运营手段，推算在线用户数和并发用户数，这些指标将成为系统非功能性设计的重要依据
  - 吞吐量
    - 定义
      - 吞吐量指单位时间内系统处理的请求数量，体现系统的整体处理能力
      - 对于网站，可以用"请求数/秒"或是“页面数/秒”来衡量，也可以用"访问人数/天"或是"处理的业务数/小时"等来衡量
      - TPS(每秒事务数)是吞吐量的一个常用量化指标
      - 此外还有HPS(每秒HTTP请求数)、QPS(每秒查询数)等
  - 性能计数器
    - 定义
      - 性能计数器是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。
      - 这些指标也是系统监控的重要参数，对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常
    - 扩展
      - System Load指系统负载，是当前正在被CPU执行和等待被CPU执行的进程数目总和，是反映系统忙闲程度的重要指标。Load的理想值是CPU的数目，Load值低于CPU数目的时候，表示CPU有空闲，资源存在浪费。Load值高于CPU数目的时候，表示进程在排队等待CPU调度，表示系统资源不足，影响应用程序的执行性能。
- 4.1.3 性能测试方法
  性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试
  - 性能测试
    - 以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。
  - 负载测试
    - 对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而会下降
  - 压力测试
    - 超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。
  - 稳定性测试
    - 被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。
    - 在不同生产环境、不同时间点的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力
- 4.1.4 性能测试报告
  - 测试结果报告能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息
  - 性能测试报告示例

- 4.1.5 性能优化策略
  如果性能测试结果不能满足设计或业务需求，那么就需要寻找系统瓶颈，分而治之，逐步优化
  - 性能分析
    - 原因
      - 大型网站系统结构复杂，用户从浏览器发出请求直到数据库完成操作事务，中间需要经过很多环节，如果测试或者用户报告网站响应缓慢，存在性能问题，必须对请求经历的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题
    - 手法
      - 排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同，就是首先检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期
      - 然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代理问题还是架构设计不合理，或者系统资源确实不足
  - 性能优化
    - 定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分别为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类
4.2 Web前端性能优化
一般来说Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN等
- 4.2.1 浏览器访问优化
  - 减少http请求
    - 原因
      - HTTP协议是无状态的应用层协议，意味着每次http请求都需要建立通信链路、进行数据传输，而在服务器端，每个http都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵，减少http请求的数目可有效提高访问性能
    - 做法
      - 减少http的主要手段是合并CSS、合并JavaScript、合并图片
      - 将浏览器一次访问需要的JavaScript、CSS合并成一个文件，这样浏览器就只需要一次请求。
      - 图片也可以合并，多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标点击操作，构造不同的URL
  - 使用浏览器缓存
    - 原因
      - 对一个网站而言，CSS,JavaScript、Logo、图标这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次HTTP请求都需要的，如果将这些文件缓存在浏览器中，可以极好地改善性能
    - 做法
      - 通过设置Http头中的Cache-Control和Expires的属性，可设定浏览器缓存，缓存时间可以是数天，甚至是几个月
      - 在某些时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况，可通过改变文件名实现，即更新JavaScript文件并不是更新JavaScript文件内容，而是生成一个新的JavaScript文件并更新Html文件中的引用
      - 使用浏览器缓存策略的网站在更新静态资源时，应采用逐量更新的方法，比如需要更新10个图标文件，不宜把10个文件一次全部更新，而是应一个文件一个文件逐步更新，并有一定的间隔时间，以免用户浏览器突然大量缓存失效，集中更新缓存，造成服务器负载骤增、网络堵塞的情况
  - 启用压缩
    - 原因
      - 在服务器端对文件进行压缩，在浏览器端对文件进行解压缩，可有效减少通信传输的数据量
    - 做法
      - 文本文件的压缩率可达80%以上，因此HTML、CSS、JavaScript文件启用GZip压缩可达到较好的效果
      - 但是压缩对服务器和浏览器产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑
  - CSS放在页面最上面、JS放在页面最下面
    - 原因
      - 浏览器会在下载完全部CSS之后才对整个页面进行渲染
      - 浏览器在加载JavaScript后立刻执行，有可能会阻塞整个页面，造成页面显示缓慢
    - 做法
      - 将CSS放在页面最上面，让浏览器尽快下载CSS
      - JavaScript放在页面最下面
        但如果页面解析时就要用到JavaScript，这时候放在底部就不合适了
  - 减少Cookie传输
    - 原因
      - 一方面，Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输
      - 另一方面，对于某些静态资源的访问，如CSS,JavaScript等，发送Cookie没有意义
    - 做法
      - 哪些Cookie需要写入Cookie需要慎重考虑，尽量减少Cookie中传输的数据量
      - 可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie，减少Cookie传输的次数
- 4.2.2 CDN加速
  - 是什么
    - CDN(Content Distribute Network，内容分发网络)的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户以最快的速度获取数据，即所谓网络访问第一跳，如图所示

- - 缓存内容
    - CDN能够缓存的一般是静态资源，如图片、文件、CSS、JavaScript、静态网页等，这些文件访问频度很高，将其缓存在CDN上可极大改善网页的打开速度
  - 加速原理
    - 由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，因此用户请求路由的第一跳就到达了CDN服务器，当CDN中存在浏览器请求的资源时，从CDN直接返回给浏览器
  - 优点
    - 最短路径返回响应，加快用户访问速度，减少数据中心负载压力
- 4.2.3 反向代理
  - 是什么
    - 传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。如图所
- - 作用
    - 和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网络攻击之间建立了一个屏障
    - 除了安全功能，代理服务器也可以通过配置缓存功能加速Web请求。当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器返回，加速Web请求响应速度，减轻Web服务器的负载压力
    - 有些网站会把动态内容也缓存在代理服务器上，比如维基百科及某些博客论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速用户访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的动态内容再次缓存起来
    - 反向代理也可以实现负载均衡的功能，而通过负载均衡构建的应用集群可以提高系统总体处理能力，进而改善网站高并***况下的性能
  - 优点
    - 保护网站安全
    - 通过配置缓存功能能够加速Web请求响应速度，减轻Web服务器的负载压力
    - 通过负载均衡改善网站高并***况下的性能
4.3 应用服务器性能优化
应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开发最复杂，变化最多的地方，优化手段主要有缓存、集群、异步等
- 4.3.1 分布式缓存
  网站性能优化第一定律：优先考虑使用缓存优化性能
  - 缓存的定义
    - 缓存指将数据存储在相对较高访问速度的存储介质中，以供系统处理
  - 缓存的优点
    - 一方面缓存访问速度快，可以减少数据访问的时间
    - 另一方面，如果缓存的数据是经过处理得到的，那么被缓存的数据无需重复计算即可直接使用，因此缓存还起到减少计算时间的作用
  - 缓存的原理
    - 缓存的本质是一个内存Hash表，网站应用中，数据缓存以一对Key、Value的形式存储在内存Hash表中。Hash表数据读写的时间复杂度为O(1)
  - 缓存内容
    - 缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。
    - 应用程序读取数据时，先到缓存中读取，如果读取不到或数据已经失效，再访问数据库，并将数据写入缓存，如图

- - 二八定律
    - 网站数据访问通常遵循二八定律，即80%的访问落在20%的数据上
    - 因此利用Hash表和内存的高速访问特性，将这20%的数据缓存起来，可很好地改善系统性能，提高数据读取速度，降低存储访问压力
  - 合理使用缓存
    不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。
    - 频繁修改的数据
      - 如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读取缓存，数据就已失效的情形，徒增系统负担
    - 没有热点的访问
      - 缓存使用内存作为存储，内存资源宝贵而有限，不可能将所有数据都缓存起来，只能将最新访问的数据缓存起来，而将历史数据清理出换缓存
      - 如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问并没有集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了
    - 数据不一致与脏读
      - 一般会对缓存的数据设置失效时间，一旦超过了失效时间，就要从数据库中重新加载
      - 因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到
    - 缓存可用性
      - 缓存数据丢失或缓存不可用不会影响到应用程序的处理-它可以从数据库直接获取数据。
      - 但是随着业务的发展，缓存回承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可以。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问
      - 通过分布式缓存服务器集群，将缓存数据分布到多态服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机的时候，只有部分缓存数据丢失，重新从数据库加载这部分数据不会对数据库产生很大影响
    - 缓存预热
      - 缓存中存放的是热点数据，热点数据又是缓存系统利用LRU(最近最久未用算法)对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间。
      - 新启动的缓存系统如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫做缓存预热。
      - 对于一些元数据如城市地名列表、类目信息，可以在启动时加载数据库中全部数据到缓存进行预热
    - 缓存穿透
      - 因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大压力，甚至崩溃
      - 一个简单的对策是将不存在的数据也缓存起来(其value值为null)
  - 分布式缓存架构
    - 定义
      - 分布式缓存指缓存部署在多个服务器组成的集群中，以集群的方式提供缓存服务
    - 架构方式
      - 以JBoss Cache为代表的需要更新同步的分布式缓存
      - 以Memcached为代表的不互相通信的分布式缓存
  - JBoss Cache
    - JBoss Cache的分布式缓存在集群中所有服务器中保存相同的缓存数据，当某台服务器有缓存数据更新的时候，会通知集群中其他机器更新缓存数据或清除缓存数据
    - JBoss Cache通常将应用程序和缓存部署在同一台服务器上，应用程序通常可以从本地快速获取缓存数据，但是这种方式带来的问题是缓存数据的数量受限于单一服务器的内存空间，而且当集群规模较大的时候，缓存更新信息需要同步到集群所有机器，代价太大。因此这种方案更多应用于企业应用系统中，而很少在大型网站中使用

- - Memcached
    - Memcached采用一种集中式的缓存集群管理，也被称作互不通信的分布式架构方式，缓存与应用分离部署，缓存系统部署在一组专门的服务器上
    - 应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模可以很容易地实现扩容，具有良好的可伸缩性
    - 架构特点:设计简单、性能优异、互补通信的服务器集群、海量数据可伸缩
    - 简单的通信协议
      - Memcached使用TCP协议(UDP也支持)通信
      - 其序列化协议则是一套基于文本的自定义协议，非常简单，以一个命令关键字开头，后面是一组命令操作数。例如读取一个数据的命令协议是get<key>
    - 丰富的客户端程序
      - Memcached通信协议非常简单，只要支持该协议的客户端都可以和Memcached服务器通信
      - 几乎支持所有主流的网站编程语言，Java、C/C++/C#、Perl、Python、PHP、Ruby等
    - 高性能的网络通信
      - Memcached服务端通信模块基于Libevent，一个支持事件触发的网络通信程序库。
    - 高效的内存管理
      - Memcached在内存管理方面使用了固定内存分配，将内存空间分为一组slab，每个slab里又包含一组chunk，同一个slab里的每个chunk的大小是固定的，拥有相同大小chunk的slab被组织在一起，叫做slab_class
      - 存储数据时根据数据的size大小，寻找一个大于size的最小chunk将数据写入。这种内存管理方式避免了内存碎片管理的问题，内存的分配和释放都死以chunk为单位的
      - 和其他缓存一样，Memcached采用LRU算法释放最久未被访问的数据占用的空间，释放的chunk被标记为未用，等待下一个合适大小的数据写入