瞬时响应：网站的高性能架构
1.网站性能测试
性能测试是性能优化的前提和基础，也是性能优化结果的检査和度量标准。不同视角下的网站性能有不同的标准，也有不同的优化手段。
1.1不同视角下的网站性能
a.用户视角的网站性能
从用户角度,网站性能就是用户在浏览器上直观感受到的网站响应速度快还是慢。用户感受到的时间，包括用户计算机和网站服务器通信的时间、网站服务器处理的时间、 用户计算机浏览器构造请求解析响应数据的时间。在实践中，使用一些前端架构优化手段，通过优化页面HTML式样、利用浏览器端 的并发和异步特性、调整浏览器缓存策略、使用CDN服务、反向代理等手段，使浏览器 尽快地显示用户感兴趣的内容、尽可能近地获取页面内容，即使不优化应用程序和架构， 也可以很大程度地改善用户视角下的网站性能。
b.开发人员视角的网站性能
开发人员关注的主要是应用程序本身及其相关子系统的性能，包括响应延迟、系统 吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有使用缓存加速数据读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能。
c.运维人员视角的网站性能
运维人员更关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬 件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要优化手段有建 设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。
1.2性能测试指标
不同视角下有不同的性能标准，不同的标准有不同的性能测试指标，从开发和测试 人员的视角，网站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等。
a.响应时间：指应用执行一个操作需要的时间，包括从发出请求幵始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”。
b.并发数：指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于网站而言，并发数即网站并发用户数，指同时提交请求的用户数目。
c.吞吐量：指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可以用 “请求数/秒”或是“页面数/秒”来衡量，也可以用“访问人数/天”或是“处理的业务数/ 小时”等来衡量。TPS (每秒事务数)是吞吐量的一个常用量化指标，此外还有HPS (每 秒HTTP请求数）、QPS (每秒査询数)等。
d.性能计数器：它是描述服务器或操作系统性能的一些数据指标。包括System Load.对象与线程数、 内存使用、CPU使用、磁盘与网络I/O等指标。这些指标也是系统监控的重要参数，对 这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向运维和开发人员 报警，及时发现处理系统异常。
1.3性能分析与优化
大型网站结构复杂，用户从浏览器发出请求直到数据库完成操作事务，中间需要经过很多环节，如果测试或者用户报告网站响应缓慢，存在性能问题，必须对请求经历的 各个环节进行分析，排査可能出现性能瓶颈的地方，定位问题。排査一个网站的性能瓶颈和排査一个程序的性能瓶颈的手法基本相同：检査请求处 理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据， 分析影响性能的主要因素是内存、磁盘、网络、还是CPU,是代码冋题还是架构设计不合理，或者系统资源确实不足.定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类。
2. Web前端性能优化
一般说来Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、 图片服务、CDN服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN等。
2.1浏览器访问优化
a.减少http请求:合并CSS、合并JavaScript、合并图片。
b.使用浏览器缓存:对一个网站而言，CSS、JavaScript, Logo、图标这些静态资源文件更新的频率都比 较低，如果将这些文件缓存在浏览器中， 可以极好地改善性能。
c.启用压缩:在服务器端对HTML、CSS、JavaScript文件进行压缩，在浏览器端对文件解压缩，可有效减少通信传输的数 据量。
d.减少Cookie传输: 一方面，Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输，因 此哪些数据需要写入Cookie需要慎重考虑，尽量减少Cookie中传输的数据量。另一方面， 对于某些静态资源的访问，如CSS、Script等，发送Cookie没有意义，可以考虑静态资 源使用独立域名访问，避免请求静态资源时发送Cookie,减少Cookie传输的次数。
2.2 CDN加速
CDN ( Content Distribute Network,内容分发网络）的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户以最快速度获取数据，即所谓网络访问第一跳， 如图所示。由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商， 因此用户请求路由的第一跳就到达了 CDN服务器，当CDN中存在浏览器请求的资源时， 从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度，减少数据中心负载压力。
利用CDN的网站架构
CDN能够缓存的一般是静态资源，如图片、文件、CSS、Script脚本、静态网页等， 但是这些文件访问频度很高，将其缓存在CDN可极大改善网页的打开速度。
2.3 反向代理
传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反 向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。如图所示。
和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网 络攻击之间建立了一个屏障。 除了安全功能，代理服务器也可以通过配置缓存功能加速Web请求。当用户第一次 访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该 静态内容的时候，就可以直接从反向代理服务器返回，加速Web请求响应速度，减轻Web 服务器负载压力。事实上，有些网站会把动态内容也缓存在代理服务器上，比如维基百 科及某些博客论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速用户访 问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代 理会重新加载最新的动态内容再次缓存起来。此外，反向代理也可以实现负载均衡的功能，而通过负载均衡构建的应用集群可以 提高系统总体处理能力，进而改善网站高并发情况下的性能。
3.应用服务器性能优化
应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开 发最复杂，变化最多的地方，优化手段主要有缓存、集群、异步等。
3.1分布式缓存
回顾网站架构演化历程，当网站遇到性能瓶颈时，第一个想到的解决方案就是使用 缓存。在整个网站应用中，缓存几乎无所不在，既存在于浏览器，也存在于应用服务器 和数据库服务器；既可以对数据缓存，也可以对文件缓存，还可以对页面片段缓存。合 理使用缓存，对网站性能优化意义重大。网站性能优化第一定律：优先考虑使用缓存优化性能。
a.缓存的基本原理
缓存指将数据存储在相对较高访问速度的存储介质中，以供系统处理。一方面缓存访 问速度快，可以减少数据访问的时间，另一方面如果缓存的数据是经过计算处理得到的， 那么被缓存的数据无需重复计算即可直接使用，因此缓存还起到减少计算时间的作用。
缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。应用程序读取数据时，先到缓存中读取，如果读取 不到或数据已失效，再访问数据库，并将数据写入缓存.
b.合理使用缓存
频繁修改的数据：如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读 取缓存，数据就已失效的情形，徒增系统负担。一般说来，数据的读写比在2:1以上，即 写入一次缓存，在数据更新前至少读取两次，缓存才有意义。实践中，这个读写比通常 非常高，比如新浪微博的热门微博，缓存以后可能会被读取数百万次。
没有热点的访问：缓存使用内存作为存储，内存资源宝贵而有限，不可能将所有数据都缓存起来，只能将最新访问的数据缓存起来，而将历史数据清理出缓存。如果应用系统访问数据没有 热点，不遵循二八定律，即大部分数据访问并没有集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了。
数据不一致与脏读：一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。 因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段 时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的，但是具体应用仍 需慎重对待。还有一种策略是数据更新时立即更新缓存，不过这也会带来更多系统开销 和事务一致性的问题。
缓存可用性：缓存是为提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到应用程序 的处理——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库会因 为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。
实践中，有的网站通过缓存热备等手段提高缓存可用性：当某台缓存服务器宕机时， 将缓存访问切换到热备服务器上。但是这种设计显然有违缓存的初衷，缓存根本就不应 该被当做一个可靠的数据源来使用。通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上可在一定程度上 改善缓存的可用性。当一台缓存服务器宕机的时候，只有部分缓存数据丢失，重新从数 据库加载这部分数据不会对数据库产生很大影响。
缓存预热：缓存中存放的是热点数据，热点数据又是缓存系统利用LRU (最近最久未用算法） 对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间。新启动的缓存系统 如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那 么最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫作缓存预热(warm Up )0对于一些元数据如城市地名列表、类目信息，可以在启动时加载数据库中全部数据 到缓存进行预热。
缓存穿透：如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大压力，甚至 崩溃。一个简单的对策是将不存在的数据也缓存起来（其value值为mill )。
c.分布式缓存架构
分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其 架构方式有两种，一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以 Memcached为代表的不互相通信的分布式缓存。Memcached曾一度是网站分布式缓存的代名词，被大量网站使用。其简单的设计、 优异的性能、互不通信的服务器集群、海量数据可伸缩的架构令网站架构师们趋之若鹫。
3.2异步操作
使用消息队列将调用异步化，可改善网站的扩展性。事实上,使用消息队列还可改善网站系统的性能。在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下， 会对数据库造成巨大的压力，同时也使得响应延迟加剧。在使用消息队列后，用户请求 的数据发送给消息队列后立即返回，再由消息队列的消费者进程（通常情况下，该进程 通常独立部署在专门的服务器集群上）从消息队列中获取数据，异步写入数据库。由于 消息队列服务器处理速度远快于数据库（消息队列服务器也比数据库具有更好的伸缩 性)，因此用户的响应延迟可得到有效改善。即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。在电子商务网站促销活动中，合理 使用消息队列，可有效抵御促销活动刚开始大量涌入的订单对系统造成的冲击。
需要注意的是，由于数据写入消息队列后立即返回给用户，数据在后续的业务校验、 写数据库等操作可能失败，因此在使用消息队列进行业务异步处理后，需要适当修改业 务流程进行配合，如订单提交后，订单数据写入消息队列，不能立即返回用户订单提交 成功，需要在消息队列的订单消费者进程真正处理完该订单，甚至商品出库后，再通过 电子邮件或SMS消息通知用户订单成功，以免交易纠纷。
3.3使用集群
在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多台服务器 组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性。
三台Web服务器共同处理来自用户浏览器的访问请求，这样每台Web服务器需要处 理的http请求只有总并发请求数的三分之一
3.4代码优化
多线程，资源复用，数据结构，垃圾回收
4.存储性能优化
在网站应用中，海量的数据读写对磁盘访问造成巨大压力，虽然可以通过Cache解 决一部分数据读压力，但是很多时候，磁盘仍然是系统最严重的瓶颈。而且磁盘中存储 的数据是网站最重要的资产，磁盘的可用性和容错性也至关重要。
4.1 机械硬盘vs.固态硬盘
机械硬盘是目前最常用的一种硬盘.固态硬盘又称作SSD或Flash硬盘，可以像内存一样快速随机访问。而且SSD具有更小的功耗和更少的 磁盘震动与噪声。
4.2 RAID vs. HDFS
RAID (廉价磁盘冗余阵列）技术主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。目前服务器级别的计算机都支持插入多块磁盘（8块或者更多），通过使 用RAID技术，实现数据在多块磁盘上的并发读写和数据备份。
HDFS ( Hadoop分布式文件系统）中，系统在整个存储集群的多台服务器上 进行数据并发读写和备份，可以看作在服务器集群规模上实现了类似RAID的功能，因此 不需要磁盘RAID。