什么叫高性能的网站?两个网站性能架构设计方案:A方案和B方案，A方案在小于100个并发用户访问时，每个请求的响应时间是1秒，当并发请求达到200的时候，请求的响应时间将骤增到10秒。B方案不管是100个并发用户访问还是200个并发用户访问，每个请求的响应时间都差不多是1.5秒。哪个方案的性能好?如果老板说“我们要改善网站的性能”，他指的是什么?同类型的两个网站,X网站服务器平均每个请求的处理时间是500毫秒,Y网站服务器平均每个请求的处理时间是1000毫秒，为什么用户却反映Y网站的速度快呢?
网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标，同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。
网站性能测试性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的网站性能有不同的标准,也有不同的优化手段。
不同视角下的网站性能：软件工程师说到网站性能的时候，通常和用户说的不一样。
开发人员视角的网站性能：开发人员关注的主要是应用程序本身及其相关子系统的性能，包括响应延迟、吞吐量、并发处理能力、系统稳定性等技术指标。主要的优化手段有使用缓存加速数据 读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化手段改善程序性能。
运维人员视角的网站性能：运维人员更关注基础设施性能和资源利用率，如网络运营商的带宽能力、服务器硬件的配置、数据中心网络架构、服务器和网络带宽的资源利用率等。主要优化手段有建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用等。
性能测试指标：
不同视角下有不同的性能标准，不同的标准有不同的性能测试指标，从开发和测试人员的视角，网站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等。
响应时间：指应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”。表4.1列出了一些常用的系统操作需要的响应时间。
并发数：指系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于网站而言，并发数即网站并发用户数,指同时提交请求的用户数目。与网站并发用户数相对应的还有网站在线用户数（当前登录网站的用户总数）和网站系统用户数(可能访问系统的总用户数，对多数网站而言就是注册用户数)。其数量比较关系为:网站系统用户数>>网站在线用户数>>网站并发用户数在网站产品设计初期，产品经理和运营人员就需要规划不同发展阶段的网站系统用户数，并以此为基础，根据产品特性和运营手段，推算在线用户数和并发用户数。这些指标将成为系统非功能设计的重要依据。
吞吐量：指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可以用“请求数/秒”或是“页面数/秒”来衡量，也可以用“访问人数/天”或是“处理的业务数/小时”等来衡量。TPS(每秒事务数)是吞吐量的一个常用量化指标，此外还有HPS(每秒HTTP请求数)、QPS(每秒查询数）等。
性能计数器：它是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络IО 等指标。这些指标也是系统监控的重要参数，对这些指标设置报警阈值，当监控系统发现性能计数器超过阈值时，就向运维和开发人员报警，及时发现处理系统异常。
性能测试方法：性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。
性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。
负载测试：对系统不断地增加并发请求以增加系统压力，系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而会下降。
压力测试：超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。
稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。在不同生产环境、不同时间点的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。
性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓的增加访问压力，在系统测试环境中，就是不断增加测试程序的并发请求数，一般说来，性能测试遵循的抛物线规律。横坐标表示消耗的系统资源，纵坐标表示系统处理能力（吞吐量)。在开始阶段，随着并发请求数目的增加，系统使用较少的资源就达到较好的处理能力( a~b段),这一段是网站的日常运行区间，网站的绝大部分访问负载压力都集中在这一段区间,被称作性能测试，测试目标是评估系统性能是否符合需求及设计目标;随着压力的持续增加，系统处理能力增加变缓，直到达到一个最大值( c点)，这是系统的最大负载点，这一段被称作负载测试。测试目标是评估当系统因为突发事件超出日常访问压力的情况下，保证系统正常运行情况下能够承受的最大访问负载压力;超过这个点后，再增加压力，系统的处理能力反而下降，而资源消耗却更多，直到资源消耗达到极限（ d点)，这个点可以看作是系统的崩溃点，超过这个点继续加大并发请求数目，系统不能再处理任何请求，这一段被称作压力测试，测试目标是评估可能导致系统崩溃的最大访问负载压力。
性能测试反应的是系统在实际生产环境中使用时，随着用户并发访问数量的增加,系统的处理能力。与性能曲线相对应的是用户访问的等待时间（系统响应时间)，如
性能测试报告：
测试结果报告应能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息,表4.2是一个简单示例。
性能优化策略：如果性能测试结果不能满足设计或业务需求，那么就需要寻找系统瓶颈，分而治之，逐步优化。
性能分析：大型网站结构复杂，用户从浏览器发出请求直到数据库完成操作事务，中间需要经过很多环节，如果测试或者用户报告网站响应缓慢，存在性能问题，必须对请求经历的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题。 排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同:检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期;然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是 CPU，是代码问题还是架构设计不合理,或者系统资源确实不足。
性能优化：定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化3大类。
Web前端性能优化一般说来 Web前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN等。
浏览器访问优化1．减少http请求：HTTP协议是无状态的应用层协议，意味着每次 HTTP请求都需要建立通信链路、进行数据传输，而在服务器端，每个HTTP都需要启动独立的线程去处理。这些通信和服务的开销都很昂贵，减少HTTP请求的数目可有效提高访问性能。减少HTTP的主要手段是合并CSS、合并JavaScript、合并图片。将浏览器次访问需要的 JavaScript、CSS合并成一个文件，这样浏览器就只需要一次请求。图片也可以合并，多张图片合并成一张，如果每张图片都有不同的超链接，可通过CSS偏移响应鼠标点击操作，构造不同的URL。
2．使用浏览器缓存：对一个网站而言，CSS、JavaScript、Logo、图标这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次HTTP请求都需要的，如果将这些文件缓存在浏览器中,可以极好地改善性能。通过设置HTTP头中 Cache-Control和Expires的属性，可设定浏览器缓存，缓存时间可以是数天,甚至是几个月。在某些时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况，可通过改变文件名实现，即更新JavaScript文件并不是更新JavaScript 文件内容，而是生成一个新的JS文件并更新HTML文件中的引用。使用浏览器缓存策略的网站在更新静态资源时，应采用批量更新的方法。
3．启用压缩：在服务器端对文件进行压缩，在浏览器端对文件解压缩，可有效减少通信传输的数据量。文本文件的压缩效率可达80%以上，因此HTML、CSS、JavaScript文件启用GZip压缩可达到较好的效果。但是压缩对服务器和浏览器产生一定的压力，在通信带宽良好,而服务器资源不足的情况下要权衡考虑。
4.CSS 放在页面最上面、JavaScript放在页面最下面：浏览器会在下载完全部 CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS。JavaScript 则相反，浏览器在加载JavaScript 后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此JavaScript最好以仕贝R最下面。但如果页面解析时就需要用到JavaScript，这时放在底部就不合适了。
5．减少Cookie传输: 一方面，Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输，因此哪些数据需要写入Cookie需要慎重考虑,尽量减少Cookie中传输的数据量。另一方面，对于某些静态资源的访问，如 CSS、Script等，发送 Cookie没有意义，可以考虑静态资源使用独立域名访问，避免请求静态资源时发送Cookie，减少Cookie传输的次数。
CDN 加速：CDN (Content Distribute Network，内容分发网络）的本质仍然是一个缓存，而且将数据缓存在离用户最近的地方，使用户以最快速度获取数据，即所谓网络访问第一跳。
由于CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，因此用户请求路由的第一跳就到达了CDN服务器,当CDN中存在浏览器请求的资源时,从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度，减少数据中心负载压力。
CDN能够缓存的一般是静态资源，如图片、文件、CSS、Script脚本、静态网页等,但是这些文件访问频度很高，将其缓存在CDN可极大改善网页的打开速度。
反向代理：传统代理服务器位于浏览器一侧，代理浏览器将 HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在 Web服务器和可能的网络攻击之间建立了一个屏障。
除了安全功能，代理服务器也可以通过配置缓存功能加速 Web请求。当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候,就可以直接从反向代理服务器返回，加速 Web请求响应速度,减轻Web服务器负载压力。事实上，有些网站会把动态内容也缓存在代理服务器上，比如维基百科及某些博客论坛网站，把热门词条、帖子、博客缓存在反向代理服务器上加速用户访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的动态内容再次缓存起来。此外，反向代理也可以实现负载均衡的功能，而通过负载均衡构建的应用集群可以提高系统总体处理能力，进而改善网站高并发情况下的性能。
应用服务器性能优化应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，是网站开发最复杂，变化最多的地方，优化手段主要有缓存、集群、异步等。
分布式缓存：网站性能优化第一定律:优先考虑使用缓存优化性能。回顾网站架构演化历程，当网站遇到性能瓶颈时，第一个想到的解决方案就是使用缓存。在整个网站应用中，缓存几乎无所不在，既存在于浏览器，也存在于应用服务器和数据库服务器;既可以对数据缓存，也可以对文件缓存，还可以对页面片段缓存。合理使用缓存，对网站性能优化意义重大。
1．缓存的基本原理：缓存指将数据存储在相对较高访问速度的存储介质中,以供系统处理。一方面缓存访问速度快，可以减少数据访问的时间，另一方面如果缓存的数据是经过计算处理得到的，那么被缓存的数据无需重复计算即可直接使用，因此缓存还起到减少计算时间的作用。
缓存的本质是一个内存Hash表，网站应用中，数据缓存以一对 Key、Value的形式存储在内存Hash表中。Hash表数据读写的时间复杂度为o(1)，为一对KV在Hash表中的存储。
计算KV对中Key的HashCode对N的 Hash 农系，-A还以们的一标示符.Iava许多语言支持获得任意对家的HashCoae, J 以CHiaLCU 个Iot然后通Hashcode语言中 Hashcode方法包含在根对家ODject r，几主粘阳长度对Hashcode求余，计算Hash表的索引下标，最简单的是余数宏，使o Iasl 支如方法的KV对. Hash表是余数即为Hash表索引，使用该索引可直接访问得到Hash表中存储的KV对。Hash表是软件开发中常用到的一种数据结构，其设计思想在很多场景下都可以应用。
缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。应用程序读取数据时，先到缓存中读取，如果读取不到或数据已失效，再访问数据库，并将数据写入缓存。
网站数据访问通常遵循二八定律，即80%的访问落在20%的数据上，因此利用Hash表和内存的高速访问特性，将这20%的数据缓存起来，可很好地改善系统性能，提高数据读取速度，降低存储访问压力。
合理使用缓存:使用缓存对提高系统性能有很多好处，但是不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。实践中，缓存滥用的情景屡见不鲜—一过分依赖低可用的缓存系统、不恰当地使用缓存的数据访问特性等。
频繁修改的数据：如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读取缓存，数据就已失效的情形，徒增系统负担。一般说来，数据的读写比在2:1以上，即写入一次缓存，在数据更新前至少读取两次，缓存才有意义。实践中，这个读写比通常非常高，比如新浪微博的热门微博，缓存以后可能会被读取数百万次。
没有热点的访问:缓存使用内存作为存储，内存资源宝贵而有限，不可能将所有数据都缓存起来，只能将最新访问的数据缓存起来，而将历史数据清理出缓存。如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问并没有集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了。
数据不一致与脏读:一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的，但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存，不过这也会带来更多系统开销和事务一致性的问题。
缓存可用性:缓存是为提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到应用程序的处理——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。
实践中，有的网站通过缓存热备等手段提高缓存可用性:当某台缓存服务器宕机时,将缓存访问切换到热备服务器上。但是这种设计显然有违缓存的初衷，缓存根本就不应该被当做一个可靠的数据源来使用。 通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机的时候，只有部分缓存数据丢失，重新从数据库加载这部分数据不会对数据库产生很大影响。
产品在设计之初就需要一个明确的定位:什么是产品要实现的功能，什么不是产品提供的特性。在产品漫长的生命周期中，会有形形色色的困难和诱惑来改变产品的发展方向，左右摇摆、什么都想做的产品，最后有可能成为一个失去生命力的四不像。
缓存预热:
缓存中存放的是热点数据，热点数据又是缓存系统利用LRU(最近最久未用算法)对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间。新启动的缓存系统如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好在缓存系统启动时就把热点数据加载好,这个缓存预加载手段叫作缓存预热warm up )。对于一些元数据如城市地名列表、类目信息，可以在启动时加载数据库中全部数据到缓存进行预热。
缓存穿透:如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据,由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来（其value值为null )。
分布式缓存架构:分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其架构方式有两种，一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Memcached为代表的不互相通信的分布式缓存。JBoss Cache的分布式缓存在集群中所有服务器中保存相同的缓存数据，当某台服务器有缓存数据更新的时候，会通知集群中其他机器更新缓存数据或清除缓存数据，如图所示。JBoss Cache通常将应用程序和缓存部署在同一台服务器上，应用程序可从本地快速获取缓存数据，但是这种方式带来的问题是缓存数据的数量受限于单一服务器的内存空间，而且当集群规模较大的时候，缓存更新信息需要同步到集群所有机器，其代价惊人。因而这种方案更多见于企业应用系统中，而很少在大型网站使用。
大型网站需要缓存的数据量一般都很庞大，可能会需要数TB的内存做缓存，这时候就需要另一种分布式缓存，如图所示。Memcached 采用一种集中式的缓存集群管理，也被称作互不通信的分布式架构方式。缓存与应用分离部署，缓存系统部署在一组专门的服务器上，应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信，缓存集群的规模可以很容易地实现扩容，具有良好的可伸缩性。
Memcached:Memcached曾一度是网站分布式缓存的代名词，被大量网站使用。其简单的设计、优异的性能、互不通信的服务器集群、海量数据可伸缩的架构令网站架构师们趋之若鹜。
简单的通信协议:远程通信设计需要考虑两方面的要素，一是通信协议，即选择TCP协议还是UDP协议，或 HTTP协议;一是通信序列化协议，数据传输的两端，必须使用彼此可识别的数据序列化方式才能使通信得以完成，如 XML、JSON 等文本序列化协议，或者GoogleProtobuffer等二进制序列化协议。Memcached使用TCP协议（ UDP也支持）通信，其序列化协议则是一套基于文本的自定义协议，非常简单，以一个命令关键字开头，后面是一组命令操作数。例如读取一个数据的命令协议是 get 。Memcached 以后，许多NoSQL产品都借鉴了或直接支持这套协议。
丰富的客户端程序:Memcached通信协议非常简单，只要支持该协议的客户端都可以和 Memcached服务器通信，因此 Memcached 发展出非常丰富的客户端程序，几乎支持所有主流的网站编程语言，Java、C/C++/C#、Perl、Python、PHP、Ruby等，因此在混合使用多种编程语言的网站，Memcached更是如鱼得水。
高性能的网络通信:Memcached 服务端通信模块基于Libevent，支持事件触发的网络通信程序库。Libevent 的设计和实现有许多值得改善的地方，但它在稳定的长连接方面的表现却正是Memcached需要的。
高效的内存管理：内存管理中一个令人头痛的问题就是内存碎片管理。操作系统、虚拟机垃圾回收在这方面想了许多办法:压缩、复制等。Memcached使用了一个非常简单的办法——固定空间分配。Memcached将内存空间分为一组slab，每个slab里又包含一组chunk，同一个slab里的每个chunk 的大小是固定的，拥有相同大小chunk 的slab被组织在一起叫作slab_class，如图所示。存储数据时根据数据的Size大小，寻找一个大于Size的最小chunk将数据写入。这种内存管理方式避免了内存碎片管理的问题，内存的分配和释放都是以chunk为单位的。和其他缓存一样，Memcached采用LRU算法释放最近最久未被访问的数据占用的空间，释放的chunk被标记为未用，等待下一个合适大小数据的写入。当然这种方式也会带来内存浪费的问题。数据只能存入一个比它大的chunk 里而一个chunk 只能存一个数据，其他空间被浪费了。如果启动参数配置不合理，浪费会更加惊人，发现没有缓存多少数据，内存空间就用尽了。
互不通信的服务器集群架构：如上所述，正是这个特性使得 Memcached 从 JBoss Cache、OSCache等众多分布式缓存产品中脱颖而出，满足网站对海量缓存数据的需求。而其客户端路由算法一致性 Hash更成为数据存储伸缩性架构设计的经典范式(参考本书第6章)。事实上，正是集群内服务器互不通信使得集群可以做到几乎无限制的线性伸缩，这也正是目前流行的许多大数据技术的基本架构特点。虽然近些年许多NoSQL产品层出不穷，在数据持久化、支持复杂数据结构、甚至性能方面有许多产品优于Memcached，但 Memcached由于其简单、稳定、专注的特点，仍然在分布式缓存领域占据着重要地位。
异步操作：使用消息队列将调用异步化，可改善网站的扩展性事实上，使用消息队列还可改善网站系统的性能，如图所示。
在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大的压力，同时也使得响应延迟加剧。在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程（通常情况下，该进程通常独立部署在专门的服务器集群上)从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度远快于数据库（消息队列服务器也比数据库具有更好的伸缩性)，因此用户的响应延迟可得到有效改善。
消息队列具有很好的削峰作用——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。在电子商务网站促销活动中合理使用消息队列,可有效抵御促销活动刚开始大量涌入的订单对系统造成的冲击。如图所示。
需要注意的是，由于数据写入消息队列后立即返回给用户，数据在后续的业务校验、写数据库等操作可能失败，因此在使用消息队列进行业务异步处理后，需要适当修改业务流程进行配合，如订单提交后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单，甚至商品出库后，再通过电子邮件或SMS消息通知用户订单成功，以免交易纠纷。
使用集群在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性，如图所示。
三台Web服务器共同处理来自用户浏览器的访问请求，这样每台Web服务器需要处理的 http请求只有总并发请求数的三分之一，根据性能测试曲线，使服务器的并发请求数目控制在最佳运行区间，获得最佳的访问请求延迟。
代码优化网站的业务逻辑实现代码主要部署在应用服务器上，需要处理复杂的并发事务。合理优化业务代码，可以很好地改善网站性能。不同编程语言的代码优化手段有很多，这里我们概要地关注比较重要的几个方面。
多线程：多用户并发访问是网站的基本需求，大型网站的并发用户数会达到数万，单台服务器的并发用户也会达到数百。CGI编程时代,每个用户请求都会创建一个独立的系统进程去处理。由于线程比进程更轻量，更少占有系统资源，切换代价更小，所以目前主要的Web 应用服务器都采用多线程的方式响应并发用户请求，因此网站开发天然就是多线程编程。
编程上，解决线程安全的主要手段有如下几点。将对象设计为无状态对象:所谓无状态对象是指对象本身不存储状态信息（对象无成员变量，或者成员变量也是无状态对象)，这样多线程并发访问的时候就不会出现状态不一致，Java Web开发中常用的Servlet对象就设计为无状态对象，可以被应用服务器多线程并发调用处理用户请求。而 Web开发中常用的贫血模型对象都是些无状态对象。不过从面向对象设计的角度看，无状态对象是一种不良设计。
使用局部对象:即在方法内部创建对象，这些对象会被每个进入该方法的线程创建，除非程序有意识地将这些对象传递给其他线程，否则不会出现对象被多线程并发访问的情形。
并发访问资源时使用锁:即多线程访问资源的时候，通过锁的方式使多线程并发操作转化为顺序操作，从而避免资源被并发修改。随着操作系统和编程语言的进步，出现各种轻量级锁，使得运行期线程获取锁和释放锁的代价都变得更小，但是锁导致线程同步顺序执行，可能会对系统性能产生严重影响。
资源复用：系统运行时，要尽量减少那些开销很大的系统资源的创建和销毁，比如数据库连接、网络通信连接、线程、复杂对象等。从编程角度，资源复用主要有两种模式:单例( Singleton）和对象池（ Object Pool )。
数据结构：早期关于程序的一个定义是，程序就是数据结构+算法，数据结构对于编程的重要性不言而喻。在不同场景中合理使用恰当的数据结构，灵活组合各种数据结构改善数据读写和计算特性可极大优化程序的性能。
垃圾回收：如果Web应用运行在JVM等具有垃圾回收功能的环境中,那么垃圾回收可能会对系统的性能特性产生巨大影响。理解垃圾回收机制有助于程序优化和参数调优，以及编写内存安全的代码。
存储性能优化在网站应用中，海量的数据读写对磁盘访问造成巨大压力，虽然可以通过Cache 解决一部分数据读压力，但是很多时候，磁盘仍然是系统最严重的瓶颈。而且磁盘中存储的数据是网站最重要的资产，磁盘的可用性和容错性也至关重要。
机械硬盘vs.固态硬盘：机械硬盘是目前最常用的一种硬盘，通过马达驱动磁头臂，带动磁头到指定的磁盘位置访问数据，由于每次访问数据都需要移动磁头臂，因此机械硬盘在数据连续访问(要访问的数据存储在连续的磁盘空间上)和随机访问（要访问的数据存储在不连续的磁盘空间)时，由于移动磁头臂的次数相差巨大，性能表现差别也非常大。
B+树vs.LSM树：本书前面提到，由于传统的机械磁盘具有快速顺序读写、慢速随机读写的访问特性,这个特性对磁盘存储结构和算法的选择影响甚大。
RAID vs. HDFS：RAID（廉价磁盘冗余阵列)技术主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。目前服务器级别的计算机都支持插入多块磁盘（8块或者更多)，通过使用RAID技术，实现数据在多块磁盘上的并发读写和数据备份。
小结网站性能优化技术是在网站性能遇到问题时的解决方案。而网站的性能问题很多是在用户高并发访问时产生的，所以网站性能优化的主要工作是改善高并发用户访问情况下的网站响应速度。本章开篇所举的例子，当老板说“我们要改善网站性能”的时候，他期望的是在A方案的基础上，不管是100个并发访问还是200个并发访问，响应时间都能达到1秒。而架构师能做到的，则是利用分布式的方案改善网站并发特性，由于分布式不可避免地会带来架构复杂、网络通信延迟等问题，所以最终设计出来的可能是B方案:缩短高并发访问响应延迟的同时，却延长了原来低并发访问时的响应延迟。架构师对这种可能性要心中有数，合理调整相关各方对性能优化的心理预期。
