对于网站性能优的经验总结.doc

对于网站性能优化的经验总结 性能优化涉及面很广。一般而言，性能优化指降低响应时间和提高系统吞吐量两个方面，但在流量高峰时候，性能问题往往会表现为服务可用性下降，所以性能优化也可以包括提高服务可用性。在某些情况下，降低响应时间、提高系统吞吐量和提高服务可用性三者相互矛盾，不可兼得。例如：增加缓存可以降低平均响应时间，但是处理线程数量会因为缓存过大而有所限制，从而降低系统吞吐量；为了提高服务可用性，对异常请求重复调用是一个常用的做法，但是这会提高响应时间并降低系统吞吐量。 对于很多像美团这样的公司，它们的系统会面临如下三个挑战：1. 日益增长的用户数量，2. 日渐复杂的业务，3. 急剧膨胀的数据。这些挑战对于性能优化而言表现为：在保持和降低系统TP95响应时间（指的是将一段时间内的请求响应时间从低到高排序，高于95%请求响应时间的下确界）的前提下，不断提高系统吞吐量，提升流量高峰时期的服务可用性。这种场景下，三者的目标和改进方法取得了比较好的一致。本文主要目标是为类似的场景提供优化方案，确保系统在流量高峰时期的快速响应和高可用。 文章第一部分是介绍，包括采用模式方式讲解的优点，文章所采用案例的说明，以及后面部分用到的一些设计原则；第二部分介绍几种典型的性能恶化模式，阐述导致系统性能恶化，服务可用性降低的典型场景以及形成恶化循环的过程；第三部分是文章重点，阐述典型的性能优化模式，这些模式或者可以使服务远离恶化模式，或者直接对服务性能进行优化；文章最后一部分进行总结，并对未来可能出现的新模式进行展望。 介绍模式讲解方式关于性能优化的文章和图书已有很多，但就我所知，还没有采用模式的方式去讲解的。本文借鉴《设计模式》（Design Patterns-Elements of Reusable Object-Oriented Software）对设计模式的阐述方式，首先为每一种性能优化模式取一个贴切的名字，便于读者快速理解和深刻记忆，接着讲解该模式的动机和原理，然后结合作者在美团的具体工作案例进行深度剖析，最后总结采用该模式的优点以及需要付出的代价。简而言之，本文采用命名--原理和动机--具体案例--缺点和优点的四阶段方式进行性能优化模式讲解。与其他方式相比，采用模式进行讲解有两个方面的优点：一方面，读者不仅仅能够掌握优化手段，而且能够了解采用该手段进行性能优化的场景以及所需付出的代价，这有利于读者全面理解和灵活应用；另一方面，模式解决的是特定应用场景下的一类问题，所以应用场景描述贯穿于模式讲解之中。如此，即使读者对原理不太了解，只要碰到的问题符合某个特定模式的应用场景（这往往比理解原理要简单），就可以采用对应的手段进行优化，进一步促进读者对模式的理解和掌握。 案例说明文章的所有案例都来自于美团的真实项目。出于两方面的考虑，作者做了一定的简化和抽象：一方面，系统可以优化的问题众多，而一个特定的模式只能解决几类问题，所以在案例分析过程中会突出与模式相关的问题；另一方面，任何一类问题都需要多维度数据去描述，而应用性能优化模式的前提是多维度数据的组合值超过了某个临界点，但是精确定义每个维度数值的临界点是一件很难的事情，更别说多维度数据组合之后临界点。因此有必要对案例做一些简化，确保相关取值范围得到满足。基于以上以及其他原因，作者所给出的解决方案只是可行性方案，并不保证其是所碰到问题的最佳解决方案。 案例涉及的所有项目都是基于Java语言开发的，严格地讲，所有模式适用的场景是基于Java语言搭建的服务。从另外一方面讲，Java和C++的主要区别在于垃圾回收机制，所以，除去和垃圾回收机制紧密相关的模式之外，文章所描述的模式也适用于采用C++语言搭建的服务。对于基于其他语言开发的服务，读者在阅读以及实践的过程中需要考虑语言之间的差别。 设计原则必须说明，本文中各种模式所要解决的问题之所以会出现，部分是因为工程师运用了某些深层次的设计原则。有些设计原则看上去和优秀的设计理念相悖，模式所解决的问题似乎完全可以避免，但是它们却被广泛使用。存在即合理，世界上没有完美的设计方案，任何方案都是一系列设计原则的妥协结果，所以本文主要关注点是解决所碰到的问题而不是如何绕过这些设计原则。下面对文中重要的设计原则进行详细阐述，在后面需要运用该原则时将不再解释。 最小可用原则最小可用原则（快速接入原则）有两个关注点：1. 强调快速接入，快速完成；2. 实现核心功能可用。这是一个被普遍运用的原则，其目标是缩短测试周期，增加试错机会，避免过度设计。为了快速接入就必须最大限度地利用已有的解决方案或系统。从另外一个角度讲，一个解决方案或系统只要能够满足基本需求，就满足最小可用原则的应用需求。过度强调快速接入原则会导致重构风险的增加，原则上讲，基于该原则去设计系统需要为重构做