一 应用无状态（淘宝session框架）

       俗话说，一个系 统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢？咱们试想一下，假如我们在session中保存了大量与客户端的状态信 息的话，那么当保存状态信息的server宕机的时候，我们怎么办？通常来说，我们都是通过集群来解决这个问题，而通常 所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采 用的集群节点广播复制，jboss采 用的配对复制等session状 态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的 通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的 水平伸缩。

        OK， 上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。幸运的是淘 宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现，主要将状态 保存到了cookie里 面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但 是采用客户端cookie的 方式来保存状态也会遇到限制，比如每个cookie一般不能超过4K的大小，同时很多浏览器都限制一个站点最 多保存20个cookie.淘 宝cookie框 架采用的是“多值cookie”， 就是一个组合键对应多个cookie的 值，这样不仅可以防止cookie数 量超过20， 同时还节省了cookie存 储有效信息的空间，因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

        除 了淘宝目前的session框 架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session 服 务器，session服 务器将session保 存到缓存中，session服 务器后端再配有底层持久性数据源，比如数据库，文件系统等等。

二 有效使用缓存（Tair）

        做 互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场 景。

        一 般来说缓存根据与应用程序的远近程度不同可以分为：local cache 和 remote cache。 一般系统中要么采用local cache，要么采用remote cache,两者混合使用的话对 于local cache和remote cache的数据一致性处理会变 大比较麻烦.

        在 大部分情况下,我 们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存.  对 于一些读写比不高，同时对数据安全性需求不高的数据，我们可以将其缓存起来从而减少对底层数据库的访问,比如 统计商品的访问次数,统 计API的 调用量等等,可 以采用先写内存缓存然后延迟持久化到数据库，这样可以大大减少对数据库的写压力。

        OK， 我以店铺线的系统为例，在用户浏览店铺的时候，比如店铺介绍，店铺交流区页面，店铺服务条款页面，店铺试衣间页面，以及店铺内搜索界面这些界面更新不是非 常频繁，因此适合放到缓存中，这样可以大大减低DB的负载。另外宝贝详情页面相对也更新比较 少，因此也适合放到缓存中来减低DB负载。

三 应用拆分（HSF）

首 先，在说明应用拆分之前，我们先来回顾一下一个系统从小变大的过程中遇到的一些问题，通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。

系 统刚上线初期，用户数并不多，所有的逻辑也许都是放在一个系统中的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此 将全部的逻辑都放在一个应用未尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户 的需求，原有的系统需要增加新的功能进来，系统变得越来越复杂的时候，我们会发现系统变得越来越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那 么这个时候我们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），我们需要将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统， 不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性scale out大 大的提升了，因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统，而不会像拆分以前，每次系统压力变大的时候，我们都需要对整 个大系统进行伸缩，而这样的成本是比较大的，另外经过切分，子系统与子系统之间的耦合减低了，当某个子系统暂时不可用的时候，整体系统还是可用的，从而整 体系统的可用性也大大增强了。

因 此一个大型的互联网应用，肯定是要经过拆分，因为只有拆分了，系统的扩展性，维护性,伸缩性，可用性才会变的更好。但是拆分也给系 统带来了问题，就是子系统之间如何通信的问题，而具体的通信方式有哪些呢？一般有同步通信和异步通信，这里我们首先来说下同步通信，下面的主题“消息系 统”会说到异步通信。既然需要通信，这个时候一个高性能的远程调用框架就显得非常总要啦，因此咱们淘宝也有了自己的HSF框 架。

上 面所说的都是拆分的好处，但是拆分以后必然的也会带来新的问题，除了刚才说的子系统通信问题外，最值得关注的问题就是系统之间的依赖关系，因为系统多了， 系统的依赖关系就会变得复杂，此时就需要更好的去关注拆分标准，比如能否将一些有依赖的系统进行垂直化，使得这些系统的功能尽量的垂直，这也是目前淘宝正 在做的系统垂直化，同时一定要注意系统之间的循环依赖，如果出现循环依赖一定要小心，因为这可能导致系统连锁启动失败。

OK， 既然明白了拆分的重要性，我们看看随着淘宝的发展，淘宝本身是如何拆分系统的。

首 先我们来看以下这个图：

从 上面的图可以看出淘宝系统的一个演变过程，在这个演变的过程中，我们所说的拆分就出现V2.2和V3.0之 间。在V2.2版 本中，淘宝几乎所有的逻辑都放在(Denali)系统中，这样导致的问题就是系统扩展和修改非常麻烦，并且更加致命的是随 着淘宝业务量的增加，如果按照V2.2的架构已经没有办法支撑以后淘宝的快速发展，因此大家决定对整个系统进行拆分，最 终V3.0版 本的淘宝系统架构图如下：

从 上图可以看出V3.0版 本的系统对整个系统进行了水平和垂直两个方向的拆分，水平方向上，按照功能分为交易，评价，用户，商品等系统，同样垂直方向上，划分为业务系统，核心业务 系统以及以及基础服务，这样以来，各个系统都可以独立维护和独立的进行水平伸缩，比如交易系统可以在不影响其它系统的情况下独立的进行水平伸缩以及功能扩 展。

 从上面可以看出，一个大型系统要想变得可维 护，可扩展，可伸缩，我们必须的对它进行拆分，拆分必然也带来系统之间如何通信以及系统之间依赖管理等问题，关于通信方面，淘宝目前独立开发了自己的高性 能服务框架HSF， 此框架主要解决了淘宝目前所有子系统之间的同步和异步通信（目前HSF主要用于同步场合，FutureTask方 式的调用场景还比较少）。至于系统间的依赖管理，目前淘宝还做的不够好，这应该也是我们以后努力解决的问题。

四 数据库拆分（TDDL）

        在 前面“应用拆分”主题中，我们提到了一个大型互联网应用需要进行良好的拆分，而那里我们仅仅说了”应用级别”的拆 分，其实我们的互联网应用除了应用级别的拆分以外，还有另外一个很重要的层面就是存储如何拆分的。因此这个主题主要涉及到如何对存储系统，通常就是所说的RDBMS进 行拆分。

好 了，确定了这个小节的主题之后，我们回顾一下，一个互联网应用从小变大的过程中遇到的一些问题，通过遇到的问题来引出我们拆分RDBMS的 重要性。

系 统刚开始的时候，因为系统刚上线，用户不多，那个时候，所有的数据都放在了同一个数据库中，这个时候因为用户少压力小，一个数据库完全可以应付的了，但是 随着运营那些哥们辛苦的呐喊和拼命的推广以后，突然有一天发现，oh,god,用户数量突然变多了起来，随之而 来的就是数据库这哥们受不了，它终于在某一天大家都和惬意的时候挂掉啦。此时，咱们搞技术的哥们，就去看看究竟是啥原因，我们查了查以后，发现原来是数据 库读取压力太大了，此时咱们都清楚是到了读写分离的时候，这个时候我们会配置一个server为master节 点，然后配几个salve节 点，这样以来通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统终于又恢复了正常，开 始正常运行了。但是好景还是不长，有一天我们发现master这哥们撑不住了，它负载老高了，汗 流浃背，随时都有翘掉的风险，这个时候就需要咱们垂直分区啦（也就是所谓的分库），比如将商品信息，用户信息，交易信息分别存储到不同的数据库中，同时还 可以针对商品信息的库采用master，salve模式，OK， 通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样数据库的压力终于有恢复 到正常状态。但是是不是这样，我们就可以高枕无忧了呢？NO,这个NO， 不是我说的，是前辈们通过经验总结出来的，随着用户量的不断增加，你会发现系统中的某些表会变的异常庞大，比如好友关系表，店铺的参数配置表等，这个时候 无论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，因此此时就需要我们进行“水平分区”了（这就是俗话说的分表，或者说sharding）.

OK,上 面说了一大堆，无非就是告诉大家一个事实“数据库是系统中最不容易scale out的一层”，一个大型的互联网 应用必然会经过一个从单一DB server,到Master/salve,再到垂直分区（分 库），然后再到水平分区（分表，sharding）的过程，而在这个过程中，Master/salve 以 及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查 询数据，如何平衡各个shards的 负载等等，这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。

拿 淘宝目前的情况来说，淘宝目前也正在从昂贵的高端存储（小型机+ORACLE）切换到MYSQL,切 换到MYSQL以 后，势必会遇到垂直分区（分库）以及水平分区（Sharding）的问题，因此目前淘宝根据自 己的业务特点也开发了自己的TDDL框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制。

五 异步通信（Notify）

在”远 程调用框架”的 介绍中,我 们说了一个大型的系统为了扩展性和伸缩性方面的需求,肯定是要进行拆分,但是 拆分了以后,子 系统之间如何通信就成了我们首要的问题,在”远程调用框架”小节 中,我 们说了同步通信在一个大型分布式系统中的应用,那么这一小节我们就来说说异步通信.好了,既 然说到了异步通信,那 么”消 息中间件”就 要登场了,采 用异步通信这其实也是关系到系统的伸缩性,以及最大化的对各个子系统进行解耦.

说 到异步通信，我们需要关注的一点是这里的异步一定是根据业务特点来的，一定是针对业务的异步，通常适合异步的场合是一些松耦合的通信场合，而对于本身业务 上关联度比较大的业务系统之间，我们还是要采用同步通信比较靠谱。

OK,那 么下一步我们说说异步能给系统带来什么样子的好处。首先我们想想，假如系统有A和B两个 子系统构成，假如A和B是 同步通信的话，那么要想使得系统整体伸缩性提高必须同时对A和B进行 伸缩，这就影响了对整个系统进行scale out.其次，同步调用还会影响到可用性，从数学推理的角度来说，A同 步调用B， 如果A可 用，那么B可 用，逆否命题就是如果B不 可用，那么A也 不可用，这将大大影响到系统可用性，再次，系统之间异步通信以后可以大大提高系统的响应时间，使得每个请求的响应时间变短，从而提高用户体验，因此异步在 提高了系统的伸缩性以及可用性的同时，也大大的增强了请求的响应时间（当然了，请求的总体处理时间也许不会变少）。

下 面我们就以淘宝的业务来看看异步在淘宝的具体应用。交易系统会与很多其它的业务系统交 互，如果在一次交易过程中采用同步调用的话，这就要求要向交易成功，必须依赖的所有系统都可用，而如果采用异步通信以后，交易系 统借助于消息中间件Notify和 其它的系统进行了解耦，这样以来当其它的系统不可用的时候，也不会影响到某此交易，从而提高了系统的可用性。

最后，关于异步方面的讨论，我可以 推荐大家一些资源：

 1 . J2EE meets web2.0

 2. Ebay架构特点(HPTS 2009)

六 非结构化数据存储 ( TFS,NOSQL)

        在 一个大型的互联网应用当中，我们会发现并不是所有的数据都是结构化的，比如一些配置文件，一个用户对应的动态，以及一次交易的快照等信息，这些信息一般不 适合保存到RDBMS中， 它们更符合一种Key-value的 结构，另外还有一类数据，数据量非常的大，但是实时性要求不高，此时这些数据也需要通过另外的一种存储方式进行存储，另外一些静态文件，比如各个商品的图 片，商品描述等信息，这些信息因为比较大，放入RDBMS会引起读取性能问题，从而影响到其它 的数据读取性能，因此这些信息也需要和其它信息分开存储，而一般的互联网应用系统都会选择把这些信息保存到分布式文件系统中，因此淘宝目前也开发了自己的 分布式文件系统TFS，TFS目 前限制了文件大小为2M， 适合于一些小于2M数 据的存放。

        随 着互联网的发展，业界从08年 下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论，一致性，可用性和分区容错性3者 不能同时满足，最多只能同时满足两个，我们传统的关系数据采用了ACID的事务策略，而ACID的 事务策略更加讲究的是一种高一致性而降低了可用性的需求，但是互联网应用往往对可用性的要求要略高于一致性的需求，这个时候我们就需要避免采用数据的ACID事 务策略，转而采用BASE事 务策略，BASE事 务策略是基本可用性，事务软状态以及最终一致性的缩写，通过BASE事务策略，我们可以通过最终一致性来提 升系统的可用性，这也是目前很多NOSQL产品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，这些产品非常适合一些非结构化的数据，比如key-value形 式的数据存储，并且这些产品有个很好的优点就是水平伸缩性。目前淘宝也在研究和使用一些成熟的NOSQL产品。

七 监控、预警系统

       对于大型的系统 来说，唯一可靠的就是系统的各个部分是不可靠。

因 为一个大型的分布式系统中势必会涉及到各种各样的设备，比如网络交换机，普通PC机，各种型号的网卡，硬盘，内存等等，而这 些东东都在数量非常多的时候，出现错误的概率也会变大，因此我们需要时时刻刻监控系统的状态，而监控也有粒度的粗细之分，粒度粗一点的话，我们需要对整个 应用系统进行监控，比如目前的系统网络流量是多少，内存利用率是多少，IO，CPU的 负载是多少，服务的访问压力是多少，服务的响应时间是多少等这一系列的监控，而细粒度一点的话，我们就需对比如应用中的某个功能，某个URL的 访问量是多，每个页面的PV是 多少，页面每天占用的带宽是多少，页面渲染时间是多少，静态资源比如图片每天占用的带宽是多少等等进行进一步细粒度的监控。因此一个监控系统就变得必不可 少了。

前 面说了一个监控系统的重要性，有了监控系统以后，更重要的是要和预警系统结合起来，比如当某个页面访问量增多的时候，系统能自动预警，某台Server的CPU和 内存占用率突然变大的时候，系统也能自动预警，当并发请求丢失严重的时候，系统也能自动预警等等，这样以来通过监控系统和预警系统的结合可以使得我们能快 速响应系统出现的问题，提高系统的稳定性和可用性。

八 配置统一管理

       一个大型的分布 式应用，一般都是有很多节点构成的，如果每次一个新的节点加入都要更改其它节点的配置，或者每次删除一个节点也要更改配置的话，这样不仅不利于系统的维护 和管理，同时也更加容易引入错误。另外很多时候集群中的很多系统的配置都是一样的，如果不进行统一的配置管理，就需要再所有的系统上维护一份配置，这样会 造成配置的管理维护很麻烦，而通过一个统一的配置管理可以使得这些问题得到很好的解决，当有新的节点加入或者删除的时候，配置管理系统可以通知各个节点更 新配置，从而达到所有节点的配置一致性，这样既方便也不会出错。

在中国， 开源的LAMP栈是最流行的网络架构，它使用PHP开发，运行在Apache服务器上，以MySQL作为数据库，所有这些都运行在Linux上。它是个可靠的平台，运行良好，是现在全球最 流行的Internet系统架构。然而，我们很难对其规模进行正确的扩展并保持安全性，因为每个应用层都有其自身的问题、缺陷和最佳实践。我们的工作就是 帮助企业用最低的操作成本来创建并运行高性能的、可伸缩的、安全的系统，因此对于这类问题我们有很丰富的经验。

当前的实际情况是，很多网站都是由开发人员 快速而廉价地创建，通常没有任何IT人员或者经理，只是由程序员来管理系统。造成的结果是，虽然花费很低的成本网站就可以开始运行，但是当拥有大量用户、 需要扩展规模的时候，通常就会面临真正的问题。毕竟，中国拥有三亿八千万的Internet用户，如果其中的0.01%访问这个站点，就很容易引发25 万~50万的页面访问量。这些问题在各个级别上都会产生，下面总结的规则是对最一般的问题进行概述，并且说明为什么这些规则如此重要，以及最好采用什么方 法来修正它们。遵循这些建议的站点会提高它的可伸缩性、安全性以及操作上的稳定性。

使用合适的会话管理
第 一个想到的扩展系统的方法就是添加更多硬件。例如，使用两台服务器而不是一台。这听着合理，但会产生潜在问题：会话管理。这对Java程序来说是很严重的问题，在PHP中也会产生可延展性问题， 对于数据库的负载尤其如此。

会话被定义为单独的最终用户登录或者连接一 段时间，其中通常会包含多个TCP/IP的HTTP连接、几个Web页面，通常还包括几十个甚至上百个页面元素，如框架、菜单、Ajax更新等。所有这些 HTTP请求都需要知道用户是谁，才能满足安全的要求，并向用户传送适当的内容，因为这些都是会话的组成部分。通常每个会话都会包括相互关联的会话数据， 如用户名、用户ID、历史、购物车、统计资料等等信息。

问题在 于，在有两台Web服务器和多个 HTTP连接的情况下，用户流量会在两台服务器之间分配和移动，服务器很难知道用户是谁，并对所有数据进行跟踪，因为每个页面或者页面的组成部分都可能来 自不同的服务器。在PHP中，通常是这样解决的，在第一次连接或登录的时候就创建一个会话ID并将其放在Cookie中，然后这个Cookie会和每个 HTTP请求一起发送。

这样做带来一个问题，接下来每段PHP脚本 都需要基于ID来查找会话数据。由于PHP无法在执行过程之间保持状态（这与Java不同），这个会话数据需要存储在某个地方，通常是在数据库中。但是， 如果复杂的页面需要在每个页面载入过程中对其进行十次查找（这是经常要做的），那就意味着每个页面都要执行10次SQL查询，这会导致数据库上很大的负 载。

在前面所举的中国 Internet用户 0.01%的例子中，可能很容易在每秒内仅仅为了管理会话就生成上百个查询。解决方法是一直使用位于Cookie中的会话ID，并且使用像 Memcached之类的服务来缓存会话数据以获得高性能。

还要注 意其中存在安全性的问题，因为黑客可 以伪造另一个用户的会话ID，这是很容易找到或看到的，特别是在公用的Wi-Fi中。解决方法是对会话ID进行恰当的加密或者签名，并将其与时间区间、 IP地址以及其他关键信息 像浏览器或者其他细节相绑定。在Internet上有很多不错的关于良好的会话管理的例子，你可以根据需要找到最适合的。

总是要考虑安全性
尽管编写像防止SQL注入和登录安全之类的 代码涉及很多安全问题，但不幸的是，几乎没有人考虑过安全性，而那些考虑到的人也没有对其进行很好地理解。而本文要关注的是操作性的系统安全。对于这类安 全，我们的焦点集中在三个安全领域：防火墙、运行的用户以及文件访问权限。

除了配置专门的硬件防火墙（像Cisco的 ASA）之外，所有服务器都还应该运行像Iptables之类的防火墙，它会保护服务器免受其他威胁和攻击。这些威胁和攻击可能来自公共的 Internet、其他服务器或本地服务器，也包括使用VPN或者SSH通道的开发和操作人员。我们仅对指定的IP开放确实需要的端口。Iptables 可能会很复杂，但是有很多不错的模板，我们通常可以使用它们来帮助客户创建Iptables。例如，默认的RedHat或者CentOS防火墙的配置说明 只有10行，显然并不实用。我们最佳实践的Iptables配置大概有5页，这其中包含了Linux所能提供的最高级的安全防范。

所有公用的服务，都应该运行在专门的用户 下，如Apache。切记永远都不要使用Root用户运行，因为这会让任何闯入到Apache的用户接管整个服务器。如果Apache只是运行在 Apache用户下或者运行在Nobody下，那么闯入Apache就不是一件容易的事情了。

Web服务器运行或者服务的文件 （像.php和.html文件）对于Web服务器的用户应该是不可写的。这意味着Apache或者Nginx用户不应该拥有Web目录的写权限。有很多方 法都可以做到这一点，而最简单的就是将这些文件为其他用户所有，然后让Apache/Nginx等用户归属于能够使用640权限读取文件的组中。这会防范 几乎所有的黑客和针对页面的攻击。

此 外，永远不要使用Ftp来上传文件，特别 是在公用的Wi-Fi环境中，因为在其中黑客很容易盗取用户名和密码。取而代之的是使用Sftp会更加安全。另外，每个雇员都应该拥有自己的用户ID和随 机密码。

使用标准的路径和安装配置

一个令人讨厌的部署问题是，开发者很少考虑 他们的软件会被部署到生产Web服务器的什么位置，以及如何部署。我们看到过许多大型的系统将它们的PHP代码部署在/home/xiaofeng或者 /web/code路径下。事实上，这两个路径都是非常不标准的，并且会带来操作和安全性的问题。当这些系统从开发环境转移到测试环境再到生产环境中时， 因为每个安装配置都是非标准的，所以经常会出现问题，这时就需要开发者调整才能够正常工作。

你应该总是使用标准的安装包和二进制文件来 安装像Apache之类的服务器。不要从源代码编译或者安装Tarball，因为这会导致长期稳定性和管理上的问题，另外在服务器上安装多个不同的版本也 会造成混淆。

Web 站点应该总是在指定的平台和 Linux发布的标准路径下进行测试和部署 ，像 RedHat 或者CentOS下的/var/www/html路径。这有助于对系统进行有效的权限管 理、备份、配置、监控以及其他操作。

Web 服务器的日志应该存放在/var /logs或者/var/logs/app_name下，而不应该位于主代码区域。这样做的原因不仅仅是因为这些标准的路径很重要，更应该关注的是，恰当 地配置服务器会将/var配置为分离的文件系统。如果应用程序突然写入了大量日志并占用所有磁盘空间，由于我们做了以上的配置就不会导致系统崩溃，或者其 他严重的问题。如果日志位于其他位置，就可能会产生问题。

总是使用日志

在Web系统中做多少日志都不为过。所有系 统都应该将重要的数据写入到日志中，不管是它们自己的日志还是系统的Syslog。Cron的Job以及其他Shell脚本或者C语言的程序，对日志都有 相应标准以及简单的函数。在Shell脚本中，只需要使用 Logger命令就可以实现日志的写入。在脚本启动/停止、重要的脚本执行以及实时数据产生的 情况下都要执行写入日志操作。这样出现问题的时候，查看主要的系统日志就可以很容易地看到发生了什么。

大型系统经常会使用专门的工具如 Local5来记录日志，并配置Syslog或者Syslog-ng来将其存放在单独的文件中，这样会更容易使用。需要注意的是，Syslog工具和 Logger（以及任何Syslog调用）默认优先使用user.notice，如有必要，你可以对其进行调整。

一个好的系统会对程序进行配置，用来打开或 者关闭日志，并可以选择在每模块或者功能的级别上应用不同级别的日志。这使得我们可以记录非常详细和强大的日志，用来分析和调试在生产操作中所发生的问 题。

大型高性能网站的十项规则

 

使用良好的数据库设计和SQL

在任何系统中，数据库通常是最大的性能瓶 颈。而影响数据库性能的最大两个问题是数据库设计和SQL代码质量。很多系统都拥有良好的或者至少是可用的数据库设计，但由于没有经过适当的性能测 试，SQL代码质量通常都会很差。这样的SQL代码在开发环境中可能运行很快，因为其中只有小数据集和最小的负载。但是当成千上万的用户同时读取数据库中 上百万条记录的时候，它就很可能会崩溃。

不幸的 是，这些问题一开始并不明显，直到系 统增大、突然开始崩溃的时候才会显现出来。在增大的过程中，数据库系统看起来运行得很快（因为数据都位于内存中，而且很少有并发的查询），并且对用户的响 应也很快，但实际上它的内部运行效率很低。这并不重要，我们关注的是在系统增大并遇到性能问题之前找到这些问题并加以解决。

关于这个问题有很多不错的书和站点进行了解 析，其中的关键工具包括慢查询日志、INNODB状态系统，以及描述当前性能的MySQL统计信息。我们见到过很多系统每秒会读取500,000条数据， 这是出现SQL问题的明显预兆，但公司往往对其一无所知直到服务器开始崩溃。

MySQL系统应该对所有数据使用 INNODB存储引擎，因为INNODB与之前的MyISAM相比，运行得更快、更稳定，并且管理性能和备份工作也更加容易和快捷。在主配置文件 中，INNODB应该被设置为默认的数据库引擎，并且系统应该不时地进行检查，看是否意外创建了MyISAM的表。

总要拥有良好的DB配置和备份

很多公司都没有良好的备份机制，也不知道如 何恰当地完成这项工作。MySQL的Dump是不够的，因为最好的备份方法是使用LVM快照和INNODB对系统进行热备份，从而得到超快的速度和超高的 可靠性。

另外，在将所有备份文件从服务器上转移出来 之前要进行压缩和加密。另外还要确保拥有设计合理的MySQL配置。MySQL默认安装使用说明中只有5~10行关于配置的说明，这根本不适合开发使用。 而我们提供给客户的最佳实践文档足足有10页那么长。文档中大约有100种有用的关于安全、性能和稳定性问题的设定，包括防止数据败坏，其中很多设定都是 非常重要的。

使用读/写数据库分离

随着系统变得越来越庞大，特别是当它们拥有 很差的SQL时，一台数据库服务器通常不足以处理负载。但是多个数据库意味着重复，除非你对数据进行了分离。更一般地，这意味着建立主/从副本系统，其中 程序会对主库编写所有的Update、Insert和Delete变更语句，而所有Select的数据都读取自从数据库（或者多个从数据库）。

尽管概念上很简单，但是想要合理、精确地实 现并不容易，这可能需要大量的代码工作。因此，即便在开始时使用同一台数据库服务器，也要尽早计划在PHP中使用分离的DB连接来进行读写操作。如果正确 地完成该项工作，那么系统就可以扩展到2台、3台甚至12台服务器，并具备高可用性和稳定性。

使用类似Memcached之类的数据库缓存

即便有了好的数据库设计、SQL和读写分 离，大型的系统仍然需要更快的性能，特别是对会话状态、好友列表以及BBS文字之类的东西。为了达到这个目的，我们可以使用像MemCached之类的数 据缓存，它是一个高性能的简单数据缓存，已经被所有最大型的站点使用。但是要小心的是，不要100%依赖于一台Memcache服务器来提高性能，因为如 果那台服务器崩溃了，就会破坏整个系统的性能。在这种情况下，应该使用2~3台Memcache服务器形成簇集架构，并且有选择地包含一个缓存准备过程， 如果缓存服务器重启，需要重新载入数据，它能够快速地载入缓存。

构建测试和开发环境

很多公司只有开发者的桌面系统和他们的生产 服务器。当系统变得越来越大、越来越复杂时，测试和管理代码就会导致严重的问题。最佳的实践是拥有两个测试系统，一个用于开发者的代码和功能的整合测试， 另一个要与生产环境完全一致，从而更容易向生产环境平滑地过渡。幸运的是，现在使用云计算（或者私有云）可以轻松达到这一点。一个5~10台服务器的生产 环境，可以很容易地在办公室或者IDC中使用一台服务器来复制，从而用于测试，而这台服务器我们可以用于多个客户的项目。

使 用版本控制

最后，要对一切使用版本控制，包括测试和生 产环境的部署。很多开发者都使用SVN或者类似的方法。在理想状态下，这些方法可以被用于所有代码、脚本、HTML、图片、配置、文档和测试。版本控制应 该是代码转移到测试环境的必经之路，而不是简单地复制或者使用tar文件，因为这二者都是不可靠的。开发者应该将所有一切都签入，打上标签，然后将它们签 出到测试系统。如果所有都没问题，那么它们会将该版本签出到生产环境。

总结

不管 是在开发还是在运营过程中，创建可靠的 高性能Web系统都有很多应该注意的事项。本文试图从可操作性和可靠性的角度讨论最重要的几点。当你构建和管理站点的时候，请不要忘了这些重要的问题。遵 循这些规则会有助于确保系统长久、良好地运行。

作者简介：

Steve Mushero，ChinaNetCloud 公司联合创始人、CEO兼CTO，拥有全球20多年的技术管理经验。曾担任土豆网、Intermind和 Advanced Management Systems等多家企业CTO

译者简介：

侯伯薇，生于凤城，学在春城，做过国内和对 日项目，现在大连某保险公司工作。乐于钻研技术，同时注重业务知识，勤于思考，愿意与人交流和分享。

在一封给中国 MySQL用户的邮件中写道 “亲爱的拯救MySQL的中国签名支持者，欧盟可能无法拯救MySQL, 中国和俄罗斯可能是拯救MySQL的希望之所在。中国拥有强大、独立以及自信的反垄断主管机关，因此，我本人在此请求您的帮助。对于您的签名，我们深表感谢。如果可以的话，我们需要您的进一步帮助……”

下面是具体的参与方法
点击这个链接并且填写自己的信息提交即可
http://helpmysql.org/cn/petition

FAQ:

----------------------------------

我们还有多少时间？

时间紧迫，但您仍然可以帮上忙。如果已经太晚（不论好还是坏），我们将立即停用请愿书，并在本网站每一页面上公布结果。

在我们通知您之前，请不要相信已经结束的任何说法。这些说法可能是试图破坏本次活动的某些人散布的。

本次活动网站于2009年12月28日启动。我们越早赢得大量支持者越好。关键的日期是2010年1月4日。那一天（明年的第一个工作日）我们计划 正式向监管者、其他政府机构、议会和记者提交请愿书。之后，我们将继续收集支持，直到程序结束，而且表示持续的支持也很重要。我们可能在2010年1月或 者可能2月份进行请愿书的多次提交。

活动为何是全球性的？

甲骨文需要在全球所有主要市场取得审批。因此，我们将在世界不同地区提交请愿书。

一般而言，监管者会把数据库市场的地理范围界定为全球性的。只要想想MySQL，显然就明白了：人们可以在全球各地下载或获取MySQL，并在各地使用它。因此，您的签名支持甚至会到达您的国家以外的世界其他地方的监管者面前。

我们需要多少签名才能成功？

没有特定限值。这不是事先就知道100,000签名者就能启动政治程序（根据某些法律）的请愿。这是有关MySQL用户的关注和希望达成令MySQL今后独立于甲骨文的真正解决方案（或者至少依赖程度更小）的表达。

这不仅仅是关于绝对数字的问题，而是如何能尽快签字，而且签字是否始终以较高速度增长的问题。您越快签字，越快让其他人知道就越好。

如何处理我的数据？我能相信你吗？

我们知道如您支持本次活动那么您就信任我们，我们将证明我们是值得信赖的。

我们有明确的资料保密声明，请见请愿书页，说明您的数据将只能用于提交请愿书给监管者、其他政府机关、议会和重要、声誉良好的新闻机构记者。如我们向您发送了有关本次活动的信息，您可点击取消链接，这样您将不会收到我们的任何其他电子邮件。

你们如何向监管者、议会和新闻机构提交请愿书？谁会看到请愿书？

有时候请愿书是以打印文件的方式提交，以表明其数量庞大。但是，为了环保考虑，我们可能选择以电子格式提交大多数的请愿书。监管者、议会和重要、著 名的新闻媒体会收到它们，其中附带了不得以任何与本次活动无关的方式使用数据的明确要求，并且，新闻媒体必须签署接收上述要求的文件，并将不被允许从请愿 书中引用任何姓名和其他唯一或范围较窄的识别数据，除非他们从签字人处收到书面明示许可（包括电子邮件方式），允许在报道中提及。

处理本次案件的监管者将把请愿书放入甲骨文/太阳微电子案卷中。对于查看该卷宗有特殊的规定。例如，欧盟甲骨文律师当然会有权看到请愿书。因此，有必要让请愿书具有真正的震撼效果。

我们不要求请愿书中提供任何特殊的敏感信息，如您决定填写其中内容的，我们也不希望您在公共或私人评论字段中提供任何敏感信息。

如何能最有效地帮助请愿成功？

显然最好的第一步就是您在请愿书上签字。

在帮助倡议 部分，您可找到进一步说明和材料，以及在网站上设置的标语。

我们相信您知道其他专业的MySQL用户，并且有办法鼓励他们在请愿书上签字。

我需要现在亲自写信给欧盟吗？或者写信给本国的反垄断机构或议会，例如欧洲议会？

我们认为本次活动将产生大量的回复，当然对于各个机构而言处理完整的请愿书更加容易一些。我们尽可能通过互联网进行号召，包括通过电子邮件，除非通过直接联系能够取得明显不同的良好效果。

如果您可以代表10名或以上员工规模的公司发言，并且MySQL对贵公司很重要，或者如果您可以代表100名或以上员工规模的公司发言，而且贵公司 把MySQL用于重大业务目的，请联系贵国反垄断机构，并表达您关于甲骨文收购MySQL计划的关注。如您需要任何帮助，请使用联系表向我们提问。

• （+15分）如果简历中说到了和工作职位相符的技能超过5次以上。
• （+8分）如果简历中说到了和工作职位相符的技能3次到5次。
• （+4分）如果简历中说到了和工作职位相符的技能1次到2次。
• （+4分）Cover Letter（“求职信”或“自荐信”）提到了招聘人员。
• （+2分）简历中有Cover Letter（求职信）。
• （-10分）没有提到和职位描述相关的技能。
• （-15分）没有受过大专教育。

程序员是这样阅读简历的

• （+15分）曾经因为好玩而写过操作系统或编译器。
• （+12分）简历被Latex编译过。
• （+11分）为开源软件贡献过代码。
• （+9分）上学的时候曾经写过操作系统或编译器。
• （+8分）有一个BLOG分享技术知识。
• （+8分）编程/机器人/工程俱乐部主席。
• （+7分）编程/机器人/工程竞赛参与者。
• （+7分）在Google和Microsoft实习过。
• （+6分）使用动态语言（Python/Perl/Ruby）写过非试验性的程序。
• （+5分）知道3种或多于3种的编程语言。
• （+5分）之前的工作和目前的职位有很相似的经验。
• （+4分）有过实习经验。
• （+4分）自己创过业开过公司。
• （+4分）有一个通过Rail, PHP或ASP.NET的个人主页。
• （+3分）有一个自己域名的邮件地址。
• （+3分）改过一些由动态语言（Python/Perl/Ruby）写的程序。
• （+2分）有一个个人主页。
• （+1分）高学历，学习成绩优秀，等。
• （+0分）有奖学金。
• （+0分）在快餐店工作过。
• （-0.5分）Fackbook上有一张看上去喝醉了的照片。
• （-1分）有博士头衔。
• （-2分）有一个一般的求职信。
• （-2分）在简历中说自己懂Word/Excel。
• （-2分）在简历中有拼写和语法错误。
• （-3分）简历的字体太小。
• （-4分）所有的编程经验只是在学校中。
• （-4分）只知道一门编程语言。
• （-6分）简历有三页以上。
• （-6分）简历中有一些无关的东西。
• （-7分）得到过一些课程的认证。
• （-8分）相关专业课程很低的成绩。
• （-10分）在技能中，把Visual Basic列在第一的位置。
• （-12分）在Facebook中，有过光膀子的照片。
• （-15分）简历中的缩进同时使用了空格和Tab键。

我个人觉得其中的很多东西真是说出了程序员的那种特性。

配图
------------------------------------------------

下面这个图片来源国外，是一个关于程序员面试时的简历，被人事部门和程序员本身评审的角度不同的图片。当然，这是一个从国外面试的视角制作的图片，不过，可以看出，其中很多东西都是和国内是相同的。让我们通过这个图片也来了解一下自身吧。

PHP5.3 新版本跟随了很多新特性， 其中比较惹眼的特性之一就是支持了闭包。那么以后，我们也可以和那帮写 Ruby、Javascript 等等“高科技语言”的家伙们一样，写出非常酷的代码吗？呃，其实大部分情况下是可以的，而有些方面还是令人非常的困扰，下面慢慢道来。

很多语言的都提供了非常优雅和漂亮的操作数组的方法。在下面的例子中，会使用 PHP5.3 以及其他语言提供的闭包功能，用于展示如何“客观的”操作迭代数组。

译注：原文作者比较火星，我不了解 Groovy 以及 Scala 语言，所以这里我加上 Javascript 的实现。

在开始之前先说明下，本例子仅仅是阐明观点，并没有考虑性能等其他方面的因素。

“货比三家”

用个简单的例子开始，有下面个数组：

$nums = array(10, 20, 30, 40);

需要找出数组中大于 15 的项。那么，不考虑闭包的情况下，我们或许会这样写：

$res = array();
foreach ($nums as $n) {
    if ($n > 15) {
        $res[] = $n;
    }
}

如果语言本身有闭包支持的，那么或许会这样写（Groovy 语言）

def res = nums.findAll { it > 15 }

或者使用 Scala 语言

val res = nums filter (_ > 15)

译注：Javascript 1.6 的话会是如下

var res = nums.filter(function(c){return c > 15});

因为循环操作已被抽象起来，所以可以看到 Groovy 、Scala （以及 Javascript） 都很漂亮得用一行就可以搞定。

当然，如果使用 PHP5.3 的闭包，也可以做到

$res = array_filter($nums, function($v) { return $v > 15; });

PHP 在这方面使用了比 Scala 更多的字符，但对比先前的例子，它更简短并且能更好得阅读。

顺便说下，上面的 PHP 代码实际上是使用了 Lambda 解析式，并不是个真正的闭包，这个 并不是我们目前关注的重点。详细阐述 PHP 闭包以及 Lambda 解析式的资料，可以参考这里。

目前看来感觉都还不错，那么我们再的题目增加点难度：找到所有大于 15 的项， 然后乘以 2 再加上作用域中的的某个变量值以后再返回。

Groovy 的实现：

def x = 1
def res = nums .findAll { it > 15 } .collect { it * 2 + x }

Scala 的实现：

val x = 1
val res = nums filter (_ > 15) map (_ * 2 + x)

译注，Javascript 的实现：

var i = 1;
var res = nums.filter(function(c){return c > 15}).map(function(c){return c * 2 + i});

以及 PHP：

$x = 1;
$res = array_map(
    function($v) use ($x) { return $v * 2 + $x; },
    array_filter(
        $nums,
        function($v) { return $v > 15; })
);

光从代码量方面，现在看起来 PHP 与其他语言有出入了。先抛开代码字面上本身 的审美不谈，上面的 PHP 代码还有个额外的问题。

例如，如果需要使用数组的键而非值作比较，怎么办？是的，上面的代码就办不到了。同时，从语法角度上说，上面的代码非常难以阅读。

返璞归真，这时还是得返回老土的思路去解决问题：

$x = 1;
$res = array();
foreach ($nums as $n) {
    if ($n > 15) {
        $res[] = $n * 2 + $x;
    }
}

呼，这样看起来又很清楚了。但这个时候你或许又会迷惑了：“那还瞎折腾啥，这不就是个数组操作吗？”。

是的，好戏还在后头。这个时候该让 PHP 的某些高级特性出场，来搞定这看似有自残倾向 的“无聊问题”。

ArrayObject – 对数组的封装

PHP 有个称作 SPL 的标准库，其中包含了个叫做 ArrayObject 的类，它能提供“像数组一 样操作类”的功能，例如

$res = new ArrayObject(array(10, 20, 30, 40));
foreach ($res as $v) {
    echo "$vn";
}

ArrayObject 是个内置的类，所以你可以像其他类类操作一样封装它。

Arr - 包上糖衣

既然我们已经有了 ArrayObject 以及闭包这些特性，我们就可以开始尝试封装它：

class Arr extends ArrayObject
{
    static function make($array)
    {
        return new self($array);
    }

    function map($func)
    {
        $res = new self();
        foreach ($this as $k => $v) {
            $res[$k] = $func($k, $v);
        }
        return $res;
    }

    function filter($func)
    {
        $res = new self();
        foreach ($this as $k => $v) {
            if ($func($k, $v)) {
                $res[$k] = $v;
            }
        }
        return $res;
    }
}

好了，万事俱备。下面重写的 PHP 代码就可以解决上面提到的问题，并且看起来语法上“差 不多”了：

$res = Arr::make($nums)
    ->filter(function($k, $v) { return $v > 15; })
    ->map(function($k, $v) { return $v * 2; });

上面的代码与传统方式有何不同呢？首先，它们可以递归并形成作用链式的调用，因此可以 添加更多的类似操作。

同时，可以通过回调的两个参数分别操作数组的键以及值其项 - $k 对应键以及 $v 对应值 。这使得我们可以在闭包中使用键值，这在传统的 PHP 函数 array_fliter 中是无法实现的。

另外个带来的额外好处就是更加一致 API 调用。使用传统的 PHP 函数操作，它们有可能第一个参数是个闭包，或者是个数组，抑或是多个数组…总之谁知道呢？

这里是 Arr 类的完整源代码，还包含了其他有用的函数（类似 reduce 以及 walk），其实它 们的实现其实方式和代码类似。

博弈

这个问题其实很难回答 - 这需要根据代码的上下文以及程序员自身等众多因素决定。其实 ，当我第一眼看见 PHP 的闭包实现时，我感觉似乎回到了那很久以前的 Java 时期，当时 我在开始使用匿名内置类（anonymous inner classes）来实现闭包。当然，这虽然可以做到， 但看起来实在是些画蛇添足。PHP 闭包本身是没错，只是它的实现以及语法让我感到非常的困惑。

其他具有闭包特性的语言，它们可以非常方便的调用闭包并同时具有优雅的语法。在上面的例子 中，在 Scala 中使用传统的循环也可以工作，但你会这样写吗？而从另个方面，那么有人 说上面这个题目使用 PHP 的闭包也可以实现，但一般情况下你会这样写吗？

可以确定，PHP 闭包在些情况下可以成为锐利的军刀（例如延时执行以及资源调用方面）， 但在传统的迭代以及数组操作面前就显得有些为难。不要气馁不管怎么样， 返璞归真编写具有兼容性的、清爽的代码以及 API 是最重要的。

结束语

像所有后来加上的语法特性一样（记得当年 Java 的 Generics 特性不？以及前几年的 PHP OOP 特性），它们都需要时间磨合以及最终稳定下来。随着 PHP5.3 甚至将来的 PHP6 逐渐普及，越来越多的技巧和特性相信在不远的将来逐渐的被聪明的程序员挖掘出来。

回到最初文章开头那个题目，对比

$res = Arr::make($nums)
    ->filter(function($k, $v) { return $v > 15; })
    ->map(function($k, $v) { return $v * 2; });

以及

val res = nums filter (_ > 15) map (_ * 2)

两者之间的区别。归根结底它们仅是语法而已，本质上都是殊途同归解决了同个问题。程序 语言的应用特性不同，自然孰优孰劣也就无从比较。

最后，这里有此篇文章的代码示例， 相信可以找到更多如何使用 PHP 进行函数式迭代（当然不仅仅是这些）的心得。

-- Split --

不靠谱之博主心得

坦白讲，虽然在 PHP5.0 之前就了解过提出的新增闭包等功能，但在看到 PHP5.3 提供的闭 包以及 Lambda 功能后，与原本心理期待的还是有些出入。

甚至相对于熟悉的 JavaScript，PHP 的闭包在我看来，像是“别的语言都有了，所以我也要有” 的这种心态下的产物。

但正如上文中所言，相比 JavaScript 等其他动态语言，PHP 出于自身的应用以及实现的哲学 出发，与其他开发语言不尽相同。

因此在某些特性的调用方式、实现方法也会不一样，这难免会让熟悉另外具有类似功能的语言 的人感到的不适应。

从 PHP5.3 推出至今，还不到半年的时间，相比 JavaScript 等这些早已具有闭包等特性的 动态语言相比，自然是显得非常稚嫩。

同时，广大的开发者对于 PHP5.3 提供的包括闭包在内的新特性还在持观望态度。PHP 的闭包特性目前还是存在于实验室中，其应用于实际开发如要突破的不仅仅是语言特性 ，还要经过效率、安全性等方面的考验。

但相信，如原文作者所言，随着 PHP 版本的推进，PHP 的闭包应用场合会越来越频繁。像 当年 PHP4 转换到 PHP5 一样，对语言新特性的适应，其实是种痛并快乐着的过程。

setTimeout( function(){ alert(’你好!’); } , 0);
setInterval( callbackFunction , 100);

认为setTimeout中的问候方法会立即被执行,因为这并不是凭空而说,而是JavaScript API文档明确定义第二个参数意义为隔多少毫秒后,回调方法就会被执行. 这里设成0毫秒,理所当然就立即被执行了.
同理对setInterval的callbackFunction方法每间隔100毫秒就立即被执行深信不疑!

但随着JavaScript应用开发经验不断的增加和丰富,有一天你发现了一段怪异的代码而百思不得其解:

div.onclick = function(){
setTimeout( function(){document.getElementById(’inputField’).focus();}, 0);
};

既然是0毫秒后执行,那么还用setTimeout干什么, 此刻, 坚定的信念已开始动摇.

直到最后某一天 , 你不小心写了一段糟糕的代码:

setTimeout( function(){ while(true){} } , 100);
setTimeout( function(){ alert(’你好!’); } , 200);
setInterval( callbackFunction , 200);

第一行代码进入了死循环,但不久你就会发现,第二,第三行并不是预料中的事情,alert问候未见出现,callbacKFunction也杳无音讯!

这时你彻底迷惘了,这种情景是难以接受的,因为改变长久以来既定的认知去接受新思想的过程是痛苦的,但情事实摆在眼前,对JavaScript真理的探求并不会因为痛苦而停止,下面让我们来展开JavaScript线程和定时器探索之旅!

拔开云雾见月明

出现上面所有误区的最主要一个原因是:潜意识中认为,JavaScript引擎有多个线程在执行,JavaScript的定时器回调函数是异步执行的.

而事实上的,JavaScript使用了障眼法,在多数时候骗过了我们的眼睛,这里背光得澄清一个事实:

JavaScript引擎是单线程运行的,浏览器无论在什么时候都只且只有一个线程在运行JavaScript程序.

JavaScript引擎用单线程运行也是有意义的,单线程不必理会线程同步这些复杂的问题,问题得到简化.

那么单线程的JavaScript引擎是怎么配合浏览器内核处理这些定时器和响应浏览器事件的呢?
下面结合浏览器内核处理方式简单说明.

浏览器内核实现允许多个线程异步执行,这些线程在内核制控下相互配合以保持同步.假如某一浏览器内核的实现至少有三个常驻线 程:javascript引擎线程,界面渲染线程,浏览器事件触发线程,除些以外,也有一些执行完就终止的线程,如Http请求线程,这些异步线程都会产 生不同的异步事件,下面通过一个图来阐明单线程的JavaScript引擎与另外那些线程是怎样互动通信的.虽然每个浏览器内核实现细节不同,但这其中的 调用原理都是大同小异.

由图可看出,浏览器中的JavaScript引擎是基于事件驱动的,这里的事件可看作是浏览器派给它的各种任务,这些任务可以源自 JavaScript引擎当前执行的代码块,如调用setTimeout添加一个任务,也可来自浏览器内核的其它线程,如界面元素鼠标点击事件,定时触发 器时间到达通知,异步请求状态变更通知等.从代码角度看来任务实体就是各种回调函数,JavaScript引擎一直等待着任务队列中任务的到来.由于单线 程关系,这些任务得进行排队,一个接着一个被引擎处理.

上图t1-t2..tn表示不同的时间点,tn下面对应的小方块代表该时间点的任务,假设现在是t1时刻,引擎运行在t1对应的任务方块代码内,在这个时间点内,我们来描述一下浏览器内核其它线程的状态.

t1时刻:

GUI渲染线程:

该线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行.本文虽然重 点解释JavaScript定时机制,但这时有必要说说渲染线程,因为该线程与JavaScript引擎线程是互斥的,这容易理解,因为 JavaScript脚本是可操纵DOM元素,在修改这些元素属性同时渲染界面,那么渲染线程前后获得的元素数据就可能不一致了.

在JavaScript引擎运行脚本期间,浏览器渲染线程都是处于挂起状态的,也就是说被”冻结”了.

所以,在脚本中执行对界面进行更新操作,如添加结点,删除结点或改变结点的外观等更新并不会立即体现出来,这些操作将保存在一个队列中,待JavaScript引擎空闲时才有机会渲染出来.

GUI事件触发线程:

JavaScript脚本的执行不影响html元素事件的触发,在t1时间段内,首先是用户点击了一个鼠标键,点击被浏览器事件触发线程捕捉后形成 一个鼠标点击事件,由图可知,对于JavaScript引擎线程来说,这事件是由其它线程异步传到任务队列尾的,由于引擎正在处理t1时的任务,这个鼠标 点击事件正在等待处理.

定时触发线程:

注意这里的浏览器模型定时计数器并不是由JavaScript引擎计数的,因为JavaScript引擎是单线程的,如果处于阻塞线程状态就计不了时,它必须依赖外部来计时并触发定时,所以队列中的定时事件也是异步事件.

由图可知,在这t1的时间段内,继鼠标点击事件触发后,先前已设置的setTimeout定时也到达了,此刻对JavaScript引擎来说,定时触发线程产生了一个异步定时事件并放到任务队列中, 该事件被排到点击事件回调之后,等待处理.
同理, 还是在t1时间段内,接下来某个setInterval定时器也被添加了,由于是间隔定时,在t1段内连续被触发了两次,这两个事件被排到队尾等待处理.

可见,假如时间段t1非常长,远大于setInterval的定时间隔,那么定时触发线程就会源源不断的产生异步定时事件并放到任务队列尾而不管它 们是否已被处理,但一旦t1和最先的定时事件前面的任务已处理完,这些排列中的定时事件就依次不间断的被执行,这是因为,对于JavaScript引擎来 说,在处理队列中的各任务处理方式都是一样的,只是处理的次序不同而已.

t1过后,也就是说当前处理的任务已返回,JavaScript引擎会检查任务队列,发现当前队列非空,就取出t2下面对应的任务执行,其它时间依此类推,由此看来:

如果队列非空,引擎就从队列头取出一个任务,直到该任务处理完,即返回后引擎接着运行下一个任务,在任务没返回前队列中的其它任务是没法被执行的.

相信您现在已经很清楚JavaScript是否可多线程,也了解理解JavaScript定时器运行机制了,下面我们来对一些案例进行分析:

案例1:setTimeout与setInterval

setTimeout(function(){
   /* 代码块... */
   setTimeout(arguments.callee, 10);
}, 10);

setInterval(function(){
   /*代码块... */
 }, 10);

这两段代码看一起效果一样,其实非也,第一段中回调函数内的setTimeout是JavaScript引擎执行后再设置新的setTimeout 定时, 假定上一个回调处理完到下一个回调开始处理为一个时间间隔,理论两个setTimeout回调执行时间间隔>=10ms .第二段自setInterval设置定时后,定时触发线程就会源源不断的每隔十秒产生异步定时事件并放到任务队列尾,理论上两个setInterval 回调执行时间间隔<=10.

案例2:ajax异步请求是否真的异步?

很多同学朋友搞不清楚,既然说JavaScript是单线程运行的,那么XMLHttpRequest在连接后是否真的异步?
其实请求确实是异步的,不过这请求是由浏览器新开一个线程请求(参见上图),当请求的状态变更时,如果先前已设置回调,这异步线程就产生状态变更事件放到 JavaScript引擎的处理队列中等待处理,当任务被处理时,JavaScript引擎始终是单线程运行回调函数,具体点即还是单线程运行 onreadystatechange所设置的函数.