深入浅出Node.js(下)

（五）：Node.js的异步实现

专栏的第五篇文章《Node.js的异步实现》。之前介绍了Node.js的事件机制，也许读者对此尚会觉得意犹未尽，因为仅仅只是简单的事件机制，并不能道尽Node.js的神奇。如果Node.js是一盘别开生面的磁带，那么事件与异步分别是其A面和B面，它们共同组成了Node.js的别样之处。本文将翻转Node.js到B面，与你共同聆听。

异步I/O

在操作系统中，程序运行的空间分为内核空间和用户空间。我们常常提起的异步I/O，其实质是用户空间中的程序不用依赖内核空间中的I/O操作实际完成，即可进行后续任务。以下伪代码模仿了一个从磁盘上获取文件和一个从网络中获取文件的操作。异步I/O的效果就是getFileFromNet的调用不依赖于getFile调用的结束。

getFile("file_path");
getFileFromNet("url");

如果以上两个任务的时间分别为m和n。采用同步方式的程序要完成这两个任务的时间总花销会是m + n。但是如果是采用异步方式的程序，在两种I/O可以并行的状况下（比如网络I/O与文件I/O），时间开销将会减小为max(m, n)。

异步I/O的必要性

有的语言为了设计得使应用程序调用方便，将程序设计为同步I/O的模型。这意味着程序中的后续任务都需要等待I/O的完成。在等待I/O完成的过程中，程序无法充分利用CPU。为了充分利用CPU，和使I/O可以并行，目前有两种方式可以达到目的：

多线程单进程

多线程的设计之处就是为了在共享的程序空间中，实现并行处理任务，从而达到充分利用CPU的效果。多线程的缺点在于执行时上下文交换的开销较大，和状态同步（锁）的问题。同样它也使得程序的编写和调用复杂化。

单线程多进程

为了避免多线程造成的使用不便问题，有的语言选择了单线程保持调用简单化，采用启动多进程的方式来达到充分利用CPU和提升总体的并行处理能力。 它的缺点在于业务逻辑复杂时（涉及多个I/O调用），因为业务逻辑不能分布到多个进程之间，事务处理时长要远远大于多线程模式。

前者在性能优化上还有回旋的余地，后者的做法纯粹是一种加三倍服务器的行为。

而且现在的大型Web应用中，单机的情形是十分稀少的，一个事务往往需要跨越网络几次才能完成最终处理。如果网络速度不够理想，m和n值都将会变大，这时同步I/O的语言模型将会露出其最脆弱的状态。

这种场景下的异步I/O将会体现其优势，max(m, n)的时间开销可以有效地缓解m和n值增长带来的性能问题。而当并行任务更多的时候，m + n + …与max(m, n, …)之间的孰优孰劣更是一目了然。从这个公式中，可以了解到异步I/O在分布式环境中是多么重要，而Node.js天然地支持这种异步I/O，这是众多云计算厂商对其青睐的根本原因。

操作系统对异步I/O的支持

我们听到Node.js时，我们常常会听到异步，非阻塞，回调，事件这些词语混合在一起。其中，异步与非阻塞听起来似乎是同一回事。从实际效果的角度说，异步和非阻塞都达到了我们并行I/O的目的。但是从计算机内核I/O而言，异步/同步和阻塞/非阻塞实际上时两回事。

I/O的阻塞与非阻塞

阻塞模式的I/O会造成应用程序等待，直到I/O完成。同时操作系统也支持将I/O操作设置为非阻塞模式，这时应用程序的调用将可能在没有拿到真正数据时就立即返回了，为此应用程序需要多次调用才能确认I/O操作完全完成。

I/O的同步与异步

I/O的同步与异步出现在应用程序中。如果做阻塞I/O调用，应用程序等待调用的完成的过程就是一种同步状况。相反，I/O为非阻塞模式时，应用程序则是异步的。

异步I/O与轮询技术

当进行非阻塞I/O调用时，要读到完整的数据，应用程序需要进行多次轮询，才能确保读取数据完成，以进行下一步的操作。

轮询技术的缺点在于应用程序要主动调用，会造成占用较多CPU时间片，性能较为低下。现存的轮询技术有以下这些：

read

select

poll

epoll

pselect

kqueue

read是性能最低的一种，它通过重复调用来检查I/O的状态来完成完整数据读取。select是一种改进方案，通过对文件描述符上的事件状态来进行判断。操作系统还提供了poll、epoll等多路复用技术来提高性能。
轮询技术满足了异步I/O确保获取完整数据的保证。但是对于应用程序而言，它仍然只能算时一种同步，因为应用程序仍然需要主动去判断I/O的状态，依旧花费了很多CPU时间来等待。

上一种方法重复调用read进行轮询直到最终成功，用户程序会占用较多CPU，性能较为低下。而实际上操作系统提供了select方法来代替这种重复read轮询进行状态判断。select内部通过检查文件描述符上的事件状态来进行判断数据是否完全读取。但是对于应用程序而言它仍然只能算是一种同步，因为应用程序仍然需要主动去判断I/O的状态，依旧花费了很多CPU时间等待，select也是一种轮询。

理想的异步I/O模型

理想的异步I/O应该是应用程序发起异步调用，而不需要进行轮询，进而处理下一个任务，只需在I/O完成后通过信号或是回调将数据传递给应用程序即可。

幸运的是，在Linux下存在一种这种方式，它原生提供了一种异步非阻塞I/O方式（AIO）即是通过信号或回调来传递数据的。

不幸的是，只有Linux下有这么一种支持，而且还有缺陷（AIO仅支持内核I/O中的O_DIRECT方式读取，导致无法利用系统缓存。参见：http://forum.nginx.org/read.php?2,113524,113587#msg-113587

以上都是基于非阻塞I/O进行的设定。另一种理想的异步I/O是采用阻塞I/O，但加入多线程，将I/O操作分到多个线程上，利用线程之间的通信来模拟异步。Glibc的AIO便是这样的典型http://www.ibm.com/developerworks/linux/library/l-async/。然而遗憾在于，它存在一些难以忍受的缺陷和bug。可以简单的概述为：Linux平台下没有完美的异步I/O支持。

所幸的是，libev的作者Marc Alexander Lehmann重新实现了一个异步I/O的库：libeio。libeio实质依然是采用线程池与阻塞I/O模拟出来的异步I/O。

那么在Windows平台下的状况如何呢？而实际上，Windows有一种独有的内核异步IO方案：IOCP。IOCP的思路是真正的异步I/O方案，调用异步方法，然后等待I/O完成通知。IOCP内部依旧是通过线程实现，不同在于这些线程由系统内核接手管理。IOCP的异步模型与Node.js的异步调用模型已经十分近似。

以上两种方案则正是Node.js选择的异步I/O方案。由于Windows平台和*nix平台的差异，Node.js提供了libuv来作为抽象封装层，使得所有平台兼容性的判断都由这一层次来完成，保证上层的Node.js与下层的libeio/libev及IOCP之间各自独立。Node.js在编译期间会判断平台条件，选择性编译unix目录或是win目录下的源文件到目标程序中。

下文我们将通过解释Windows下Node.js异步I/O（IOCP）的简单例子来探寻一下从JavaScript代码到系统内核之间都发生了什么。

Node.js的异步I/O模型

很多同学在遇见Node.js后必然产生过对回调函数究竟如何被调用产生过好奇。在文件I/O这一块与普通的业务逻辑的回调函数不同在于它不是由我们自己的代码所触发，而是系统调用结束后，由系统触发的。下面我们以最简单的fs.open方法来作为例子，探索Node.js与底层之间是如何执行异步I/O调用和回调函数究竟是如何被调用执行的。

fs.open = function(path, flags, mode, callback) {
  callback = arguments[arguments.length - 1];
  if (typeof(callback) !== 'function') {
    callback = noop;
  }

mode = modeNum(mode, 438 /*=0666*/);

binding.open(pathModule._makeLong(path),
stringToFlags(flags),
mode,
callback);
};

fs.open的作用是根据指定路径和参数，去打开一个文件，从而得到一个文件描述符，是后续所有I/O操作的初始操作。

在JavaScript层面上调用的fs.open方法最终都透过node_file.cc调用到了libuv中的uv_fs_open方法，这里libuv作为封装层，分别写了两个平台下的代码实现，编译之后，只会存在一种实现被调用。

请求对象

在uv_fs_open的调用过程中，Node.js创建了一个FSReqWrap请求对象。从JavaScript传入的参数和当前方法都被封装在这个请求对象中，其中回调函数则被设置在这个对象的oncomplete_sym属性上。

req_wrap->object_->Set(oncomplete_sym, callback);

对象包装完毕后，调用QueueUserWorkItem方法将这个FSReqWrap对象推入线程池中等待执行。

QueueUserWorkItem(&uv_fs_thread_proc, req, WT_EXECUTELONGFUNCTION)

QueueUserWorkItem接受三个参数，第一个是要执行的方法，第二个是方法的上下文，第三个是执行的标志。当线程池中有可用线程的时候调用uv_fs_thread_proc方法执行。该方法会根据传入的类型调用相应的底层函数，以uv_fs_open为例，实际会调用到fs__open方法。调用完毕之后，会将获取的结果设置在req->result上。然后调用PostQueuedCompletionStatus通知我们的IOCP对象操作已经完成。

PostQueuedCompletionStatus((loop)->iocp, 0, 0, &((req)->overlapped))

PostQueuedCompletionStatus方法的作用是向创建的IOCP上相关的线程通信，线程根据执行状况和传入的参数判定退出。

至此，由JavaScript层面发起的异步调用第一阶段就此结束。

事件循环

在调用uv_fs_open方法的过程中实际上应用到了事件循环。以在Windows平台下的实现中，启动Node.js时，便创建了一个基于IOCP的事件循环loop，并一直处于执行状态。

uv_run(uv_default_loop());

每次循环中，它会调用IOCP相关的GetQueuedCompletionStatus方法检查是否线程池中有执行完的请求，如果存在，poll操作会将请求对象加入到loop的pending_reqs_tail属性上。 另一边这个循环也会不断检查loop对象上的pending_reqs_tail引用，如果有可用的请求对象，就取出请求对象的result属性作为结果传递给oncomplete_sym执行，以此达到调用JavaScript中传入的回调函数的目的。 至此，整个异步I/O的流程完成结束。其流程如下：

事件循环和请求对象构成了Node.js的异步I/O模型的两个基本元素，这也是典型的消费者生产者场景。在Windows下通过IOCP的GetQueuedCompletionStatus、PostQueuedCompletionStatus、QueueUserWorkItem方法与事件循环实。对于*nix平台下，这个流程的不同之处在与实现这些功能的方法是由libeio和libev提供。

（六）：Buffer那些事儿

作为前端的JSer，是一件非常幸福的事情，因为在字符串上从来没有出现过任何纠结的问题。我们来看看PHP对字符串长度的判断结果：

<? php 
echo strlen("0123456789");     
echo strlen("零一二三四五六七八九");     
echo mb_strlen("零一二三四五六七八九", "utf-8");      
echo "\n"; 

以上三行判断分别返回10、30、10。对于中国人而言，strlen这个方法对于Unicode的判断结果是非常让人疑惑。而看看JavaScript中对字符串长度的判断，就知道这个length属性对调用者而言是多么友好。

console.log("0123456789".length); // 10
console.log("零一二三四五六七八九".length); /10
console.log("\u00bd".length); // 1

尽管在计算机内部，一个中文字和一个英文字占用的字节位数是不同的，但对于用户而言，它们拥有相同的长度。我认为这是JavaScript中 String处理得精彩的一个点。正是由于这个原因，所有的数据从后端传输到前端被调用时，都是这般友好的字符串。所以对于前端工程师而言，他们是没有字 符串Buffer的概念的。如果你是一名前端工程师，那么从此在与Node.js打交道的过程中，一定要小心Buffer啦，因为它比传统的String 要调皮一点。

你该小心Buffer啦

像许多计算机的技术一样，都是从国外传播过来的。那些以英文作为母语的传道者们应该没有考虑过英文以外的使用者，所以你有可能看到如下这样一段代码在向你描述如何在data事件中连接字符串。

var fs = require('fs');
var rs = fs.createReadStream('testdata.md');
var data = '';
rs.on("data", function (trunk){
    data += trunk;
});
rs.on("end", function () {
    console.log(data);
});

如果这个文件读取流读取的是一个纯英文的文件，这段代码是能够正常输出的。但是如果我们再改变一下条件，将每次读取的buffer大小变成一个奇数，以模拟一个字符被分配在两个trunk中的场景。

var rs = fs.createReadStream('testdata.md', {bufferSize: 11}); 

我们将会得到以下这样的乱码输出：

事件循???和请求???象构成了Node.js???异步I/O模型的???个基本???素，这也是典???的消费???生产者场景。

造成这个问题的根源在于data += trunk语句里隐藏的错误，在默认的情况下，trunk是一个Buffer对象。这句话的实质是隐藏了toString的变换的：

data = data.toString() + trunk.toString();

由于汉字不是用一个字节来存储的，导致有被截破的汉字的存在，于是出现乱码。解决这个问题有一个简单的方案，是设置编码集：

var rs = fs.createReadStream('testdata.md', {encoding: 'utf-8', bufferSize: 11}); 

这将得到一个正常的字符串响应：

事件循环和请求对象构成了Node.js的异步I/O模型的两个基本元素，这也是典型的消费者生产者场景。 

遗憾的是目前Node.js仅支持hex、utf8、ascii、binary、base64、ucs2几种编码的转换。对于那些因为历史遗留问题依旧还生存着的GBK，GB2312等编码，该方法是无能为力的。

有趣的string_decoder

在这个例子中，如果仔细观察，会发现一件有趣的事情发生在设置编码集之后。我们提到data += trunk等价于data = data.toString() + trunk.toString()。通过以下的代码可以测试到一个汉字占用三个字节，而我们按11个字节来截取trunk的话，依旧会存在一个汉字被分割在两个trunk中的情景。

console.log("事件循环和请求对象".length);
console.log(new Buffer("事件循环和请求对象").length);

按照猜想的toString()方式，应该返回的是事件循xxx和请求xxx象才对，其中“环”字应该变成乱码才对，但是在设置了encoding（默认的utf8）之后，结果却正常显示了，这个结果十分有趣。

在好奇心的驱使下可以探查到data事件调用了string_decoder来进行编码补足的行为。通过string_decoder对象输出第一个截取Buffer(事件循xx)时，只返回事件循这个字符串，保留xx。第二次通过string_decoder对象输出时检测到上次保留的xx，将上次剩余内容和本次的Buffer进行重新拼接输出。于是达到正常输出的目的。

string_decoder，目前在文件流读取和网络流读取中都有应用到，一定程度上避免了粗鲁拼接trunk导致的乱码错误。但是，遗憾在于string_decoder目前只支持utf8编码。它的思路其实还可以扩展到其他编码上，只是最终是否会支持目前尚不可得知。

连接Buffer对象的正确方法

那么万能的适应各种编码而且正确的拼接Buffer对象的方法是什么呢？我们从Node.js在github上的源码中找出这样一段正确读取文件，并连接buffer对象的方法：

var buffers = [];
var nread = 0;
readStream.on('data', function (chunk) {
    buffers.push(chunk);
    nread += chunk.length;
});
readStream.on('end', function () {
    var buffer = null;
    switch(buffers.length) {
        case 0: buffer = new Buffer(0);
            break;
        case 1: buffer = buffers[0];
            break;
        default:
            buffer = new Buffer(nread);
            for (var i = 0, pos = 0, l = buffers.length; i < l; i++) {
                var chunk = buffers[i];
                chunk.copy(buffer, pos);
                pos += chunk.length;
            }
        break;
    }
});

在end事件中通过细腻的连接方式，最后拿到理想的Buffer对象。这时候无论是在支持的编码之间转换，还是在不支持的编码之间转换（利用iconv模块转换），都不会导致乱码。

简化连接Buffer对象的过程

上述一大段代码仅只完成了一件事情，就是连接多个Buffer对象，而这种场景需求将会在多个地方发生，所以，采用一种更优雅的方式来完成该过程是必要的。笔者基于以上的代码封装出一个bufferhelper模块，用于更简洁地处理Buffer对象。可以通过NPM进行安装：

npm install bufferhelper 

下面的例子演示了如何调用这个模块。与传统data += trunk之间只是bufferHelper.concat(chunk)的差别，既避免了错误的出现，又使得代码可以得到简化而有效地编写。

var http = require('http');  
var BufferHelper = require('bufferhelper');
http.createServer(function (request, response) {
    var bufferHelper = new BufferHelper();
    request.on("data", function (chunk) {
    bufferHelper.concat(chunk);
    });
    request.on('end', function () {
    var html = bufferHelper.toBuffer().toString();
    response.writeHead(200);
    response.end(html);
    });

}).listen(8001);

所以关于Buffer对象的操作的最佳实践是：

保持编码不变，以利于后续编码转换

使用封装方法达到简洁代码的目的

（七）：Connect模块解析（之一）

Connect模块背景

Node.js的愿望是成为一个能构建高速，可伸缩的网络应用的平台，它本身具有基于事件，异步，非阻塞，回调等特性，这在前几篇专栏中有过描述。正是基于这样的一些特性，Node.js平台上的Web框架也具有不同于其他平台的一些特性，其中Connect是众多Web框架中的佼佼者。

Connect在它的官方介绍中，它是Node的一个中间件框架。超过18个捆绑的中间件和一些精选第三方中间件。尽管Connect可能不是性能最好的Node.jsWeb框架，但它却几乎是最为流行的Web框架。为何Connect能在众多框架中胜出，其原因不外乎有如下几个：

模型简单

中间件易于组合和插拔

中间件易于定制和优化

丰富的中间件

Connect自身十分简单，其作用是基于Web服务器做中间件管理。至于如何如何处理网络请求，这些任务通过路由分派给管理的中间件们进行处理。它的处理模型仅仅只是一个中间队列，进行流式处理而已，流式处理可能性能不是最优，但是却是最易于被理解和接受。基于中间件可以自由组合和插拔的情况，优化它十分容易。

Connect模块目前在NPM仓库的MDO（被依赖最多的模块）排行第八位。但这并没有真实反映出它的价值，因为排行第五位的Express框架实际上是依赖Connect创建而成的。关于Express的介绍，将会在后续的专栏中一一为你讲解。

中间件

让我们回顾一下Node.js最简单的Web服务器是如何编写的：

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, '127.0.0.1');

我们从最朴素的Web服务器处理流程开始，可以看到HTTP模块基于事件处理网络访问无外乎两个主要的因素，请求和响应。同理的是Connect的中间件也是扮演这样一个角色，处理请求，然后响应客户端或是让下一个中间件继续处理。如下是一个中间件最朴素的原型：

function (req, res, next) {
  // 中间件
}

在中间件的上下文中，有着三个变量。分别代表请求对象、响应对象、下一个中间件。如果当前中间件调用了res.end()结束了响应，执行下一个中间件就显得没有必要。

流式处理

为了演示中间件的流式处理，我们可以看看中间件的使用形式：

var app = connect();
// Middleware
app.use(connect.staticCache());
app.use(connect.static(__dirname + '/public'));
app.use(connect.cookieParser());
app.use(connect.session());
app.use(connect.query());
app.use(connect.bodyParser());
app.use(connect.csrf());
app.use(function (req, res, next) {
  // 中间件
});
app.listen(3001);

Conncet提供use方法用于注册中间件到一个Connect对象的队列中，我们称该队列叫做中间件队列。

Conncet的部分核心代码如下，它通过use方法来维护一个中间件队列。然后在请求来临的时候，依次调用队列中的中间件，直到某个中间件不再调用下一个中间件为止。

app.stack = [];
app.use = function(route, fn){
  // …

// add the middleware
debug('use %s %s', route || '/', fn.name || 'anonymous');
this.stack.push({ route: route, handle: fn });

return this;
};

值得注意的是，必须要有一个中间件调用res.end()方法来告知客户端请求已被处理完成，否则客户端将一直处于等待状态。

流式处理也是Node.js中用于流程控制的经典模式，Connect模块是典型的应用了它。流式处理的好处在于，每一个中间层的职责都是单一的，开发者通过这个模式可以将复杂的业务逻辑进行分解。

路由

从前文可以看到其实app.use()方法接受两个参数，route和fn，既路由信息和中间件函数，一个完整的中间件，其实包含路由信息和中间件函数。路由信息的作用是过滤不匹配的URL。请求在遇见路由信息不匹配时，直接传递给下一个中间件处理。

通常在调用app.use()注册中间件时，只需要传递一个中间件函数即可。实际上这个过程中，Connect会将/作为该中间件的默认路由，它表示所有的请求都会被该中间件处理。

中间件的优势类似于Java中的过滤器，能够全局性地处理一些事务，使得业务逻辑保持简单。

任何事物均有两面性，当你调用app.use()添加中间件的时候，需要考虑的是中间件队列是否太长，因为每一层中间件的调用都是会降低性能的。为了提高性能，在添加中间件的时候，如非全局需求的，尽量附带上精确的路由信息。

以multipart中间件为例，它用于处理表单提交的文件信息，相对而言较为耗费资源。它存在潜在的问题，那就是有可能被人在客户端恶意提交文件，造成服务器资源的浪费。如果不采用路由信息加以限制，那么任何URL都可以被攻击。

app.use("/upload", connect.multipart({ uploadDir: path }));

加上精确的路由信息后，可以将问题减小。

MVC目录

借助Connect可以自由定制中间件的优势，可以自行提升性能或是设计出适合自己需要的项目。Connect自身提供了路由功能，在此基础上，可以轻松搭建MVC模式的框架，以达到开发效率和执行效率的平衡。以下是笔者项目中采用的目录结构，清晰地划分目录结构可以帮助划分代码的职责，此处仅供参考。

├── Makefile // 构建文件，通常用于启动单元测试运行等操作
├── app.js // 应用文件
├── automation  // 自动化测试目录
├── bin  // 存放启动应用相关脚本的目录
├── conf  // 配置文件目录
├── controllers  // 控制层目录
├── helpers  // 帮助类库
├── middlewares  // 自定义中间件目录
├── models  // 数据层目录
├── node_modules  // 第三方模块目录
├── package.json  // 项目包描述文件
├── public  // 静态文件目录
│   ├── images  // 图片目录
│   ├── libs  // 第三方前端JavaScript库目录
│   ├── scripts  // 前端JavaScript脚本目录
│   └── styles  // 样式表目录
├── test  // 单元测试目录
└── views  // 视图层目录

（八）：Connect模块解析（之二）静态文件中间件

上一篇专栏简单介绍了Connect模块的基本架构，它的执行模型十分简单，中间件机制也使得它十分易于扩展，具备良好的可伸缩性。在Connect的良好机制下，我们本章开始将逐步解开Connect生态圈中中间件部分，这部分给予Connect良好的功能扩展。

静态文件中间件

也许你还记得我曾经写过的Node.js静态文件服务器实战，那篇文章中我叙述了如何利用Node.js实现一个静态文件服务器的许多技术细节，包括路由实现，MIME，缓存控制，传输压缩，安全、欢迎页、断点续传等。但是这里我们不需要去亲自处理细节，Connect的static中间件为我们提供上述所有功能。代码只需寥寥3行即可：

var connect = require('connect');  
var app = connect(); 
app.use(connect.static(__dirname + '/public'));

在项目中需要临时搭建静态服务器，也无需安装apache之类的服务器，通过NPM安装Connect之后，三行代码即可解决需求。
这里需要提及的是在使用该模块的一点性能相关的细节。

动静分离

前一章提及，app.use()方法在没有指定路由信息时，相当于app.use("/", middleware)。这意味着静态文件中间件将会在处理所有路径的请求。在动静态请求混杂的场景下，静态中间件会在动态请求时也调用fs.stat来检测文件系统是否存在静态文件。这造成了不必要的系统调用，使得性能降低。
解决影响性能的方法既是动静分离。利用路由检测，避免不必要的系统调用，可以有效降低对动态请求的性能影响。

app.use('/public', connect.static(__dirname + '/public'));

在大型的应用中，动静分离通常无需到一个Node.js实例中进行，CDN的方式直接在域名上将请求分离。小型应用中，适当的进行动静分离即可避免不必要的性能损耗。

缓存策略

缓存策略包含客户端和服务端两个部分。

客户端的缓存，主要是利用浏览器对HTTP协议响应头中cache-control和expires字段的支持。浏览器在得到明确的相应头后，会将文件缓存在本地，依据cache-control和expires的值进行相应的过期策略。这使得重复访问的过程中，浏览器可以从本地缓存中读取文件，而无需从网络读取文件，提升加载速度，也可以降低对服务器的压力。

默认情况下静态中间件的最大缓存时设置为0，意味着它在浏览器关闭后就被清除。这显然不是我们所期望的结果。除非是在开发环境可以无视maxAge的设置外，生产环境请务必设置缓存，因为它能有效节省网络带宽。

app.use('/public', connect.static(__dirname + '/public', {maxAge: 86400000})); 

maxAge选项的单位为毫秒。YUI3的CDN服务器设置过期时间为10年，是一个值得参考的值。

静态文件如果在客户端被缓存，在需要清除缓存的时候，又该如何清除呢？这里的实现方法较多，一种较为推荐的做法是为文件进行md5处理。

http://some.url/some.js?md5 

当文件内容产生改变时，md5值也将发生改变，浏览器根据URL的不同会重新获取静态文件。md5的方式可以避免不必要的缓存清除，也能精确清除缓存。

由于浏览器本身缓存容量的限制，尽管我们可能设置了10年的过期时间，但是也许两天之后就被新的静态文件挤出了本地缓存。这将持续引起静态服务器的响应，也即意味着，客户端缓存并不能完全解决降低服务器压力的问题。

为了解决静态服务器重复读取磁盘造成的压力，这里需要引出第二个相关的中间件：staticCache。

app.use(connect.staticCache());  
app.use(“/public”, connect.static(__dirname + '/public', {maxAge: 86400000})); 

这是一个提供上层缓存功能的中间件，能够将磁盘中的文件加载到内存中，以提高响应速度和提高性能。
它的官方测试数据如下：

static(): 2700 rps 
node-static: 5300 rps 
static() + staticCache(): 7500 rps

另一个专门用于静态文件托管的模块叫node-static，其性能是Connect静态文件中间件的效率的两倍。但是在缓存中间件的协助下，可以弥补性能损失。

事实上，这个中间件在生产环境下并不推荐被使用，而且它将在Connect 3.0版本中被移除。但是它的实现中有值得玩味的地方，这有助于我们认识Node.js模型的优缺点。

staticCache中间件有两个主要的选项：maxObjects和maxLength。代表的是能存储多少个文件和单个文件的最大尺寸，其默认值为128和256kb。为何会有这两个选项的设定，原因在于V8有内存限制的原因，作为缓存，如果没有良好的过期策略，缓存将会无限增加，直到内存溢出。设置存储数量和单个文件大小后，可以有效抑制缓存区的大小。

事实上，该缓存还存在的缺陷是单机情况下，通常为了有效利用CPU，Node.js实例并不只有一个，多个实例进程之间将会存在冗余的缓存占用，这对于内存使用而言是浪费的。

除此之外，V8的垃圾回收机制是暂停JavaScript线程执行，通过扫描的方式决定是否回收对象。如果缓存对象过大，键太多，则扫描的时间会增加，会引起JavaScript响应业务逻辑的速度变慢。

但是这个模块并非没有存在的意义，上述提及的缺陷大多都是V8内存限制和Node.js单线程的原因。解决该问题的方式则变得明了。

风险转移是Node.js中常用于解决资源不足问题的方式，尤其是内存方面的问题。将缓存点，从Node.js实例进程中转移到第三方成熟的缓存中去即可。这可以保证：

缓存内容不冗余。

集中式缓存，减少不一致性的发生。

缓存的算法更优秀以保持较高的命中率。

让Node.js保持轻量，以解决它更擅长的问题。

Connect推荐服务器端缓存采用varnish这样的成熟缓存代理。而笔者目前的项目则是通过Redis来完成后端缓存的任务。