Web 应用是个典型的 io 数据流，
首先，浏览器发来一个 input，服务器获取之后，做一些查询或者计算，然后把生成的 output 返回给浏览器。
这些查询或计算，还会有衍生的子 io 流。
缓存的目的就是让把 input 变成一个 key，在条件允许的情况下，跳过计算，直接生成 output。在主流程中，或子流程中。
数据查询缓存
resource: http://robbinfan.com/blog/3/orm-cache
n + 1 问题
n + 1 问题是 orm 竟然被诟病的地方。什么是 n + 1 问题呢？ 比如一个用户，它写了 20 篇博客。当我们查询这个用户的首页时，需要列出他的所有博客。 “高效”的思路是使用一个 join 语句，把 user 表和 blog 表做 join，然后一条语句取出所有想要的字段。 而 orm，会先取出 user 的记录，再做 20 次遍历，分别用 20 条语句取出他所有的博客。 按照 robbin 的说法，join 语句的结果很难被缓存利用，因为它发生的场景太过特定。 但如果使用 orm，按照 n + 1 的方式取数据。由于数据缓存的粒度比较小，缓存的命中率得到了提高。 首先，orm 内置的缓存一般会在同一个连接中，缓存同一 sql 语句的结果；其次，数据库的缓存会记下特定 sql 语句的对应的结果，当再次收到相同语句时，数据库不必进行扫描，可以直接 O(1) 复杂度地返回缓存结果。
robbin 认为，在这种情况下，n + 1 的查询反而因为有效利用了缓存，而比 join 语句更快。
robbin 得出了这样的结论：即使不使用对象缓存，ORM的n+1条SQL性能仍然很有可能超过SQL的大表关联查询，而且对数据库磁盘IO造成的压力要小很多
缓存层加入
利用 redis 或者 memcached，这个话题 google 一下会有很多。
json to orm 问题
CNode 使用的是 mongoose 这个 odm 来访问 mongodb。在 mongoose 的 model 中，我们定义了不少【虚拟属性】，所谓虚拟属性，就是指：一个 user 实例，它有 first_name 和 last_name 字段，当我们定义一个名字为 full_name 的虚拟属性时，user.full_name 会根据定义的函数自动拼接 first_name 和 last_name。也就是面向对象编程中的 getter 方法。
当缓存一个 mongoose 取出的文档到 redis 时，我们会将它先装换成 json，再以字符串形式存入。 再次取出并 JSON.parse 的时候，会发现 mongoose model 定义的虚拟属性全都被丢弃了。所以这时，需要重新把这个 json 传入 model 初始化一次，得到一个 model 实例。这样，我们就恢复了原来内存中的那个 model 实例了。
数据写入缓存：
在数据库与服务端之间利用 redis
这是一个很常见的场景。比如文章的浏览数，每次文章被浏览时，浏览数都 +1。如果每次都回写数据库，不免数据量太大。加上数据库看似简单，其实做了不少关于一致性（请看官了解一下所谓【一致性】，【base】，【acid】）的检查。
而同时，浏览数并不要求保证一致性，只要大概准确就行了。
所以这时候，我们可以先将浏览数写入 redis，满足一定条件后，再回写数据库。
比如，在 controller 中，让每次浏览都在 redis 上 +1，+1 完成后，检查浏览数是否除以 10 后余数为 0（count % 10 === 0），是的话，则回写数据库，并将缓存置为 0。
缓存过期策略
可以通过过期时间来控制内容新鲜期
那么就设置设缓存过期时间。比如在一个网站上，总会有一些每日之星用户，或者今日推荐文章。
这些内容的新鲜期都很长，比如每日之星的数据，如果 20 分钟更新一次，用户也不会有异议。那么，我们在查询出这些用户后，可以将结果集存入缓存中，并设置过期时间为 20 分钟。待自动失效后，再重新查询。
无法通过过期时间来控制内容新鲜期
这时，又有两个策略了。一个是【主动过期】策略，一个是【被动过期】策略。比如想要缓存一篇文章的内容 HTML，但文章的页面中包含了评论信息。一些老文章被大量访问而无人添加评论时，缓存的效果杠杠的。但一些近期文章会被用户添加评论， 我们无法判断用户何时会添加评论，所以无法得到一个最佳实践的文章过期时间。
主动过期
顾名思义，主动地去 delete 缓存。还是上面的文章例子。我们可以在评论的 model 中，设置一个回调逻辑。每当评论被更新时，同时去删除评论所对应的文章的缓存内容。
被动过期
被动过期也不是完全不需要回调逻辑，只是相对主动过期来说。它不必理解缓存层的存在。
还是上面的例子，当我们缓存一个文章页面时，不仅以文章的 id 为 cache key，还在 cache key 中拼入文章的 update_at 字段。
当评论更新时，让评论去 touch 一下对应的文章，更新文章的最后修改日期。那么当用户再次访问文章时，由于 cache key 变动，过期的内容就不会被展现，从而实现了被动过期。
同样的例子还有，一篇文章是以 markdown 写成，每次输出的时候，都要进行 markdown 渲染，这是个耗时操作。于是我们可以将 'markdown_result_' + artical.id + artical.updated_at 作为 key，来缓存 markdown 的渲染结果。每当文章更新时，被动地废弃旧有的缓存结果。
当然，这里不能说主动过期好，还是被动过期好。细心的看客也许在上面两个例子中发现了问题，那就是，当文章的内容没有进行改变，而评论添加时，文章却要重新渲染 markdown，可渲染结果其实是一样的。
HTML 片段缓存
resource: https://ruby-china.org/topics/21488
以 CNode 为例，我简单地划分了 1 2 3 4 四个部分。每个部分在逻辑上都是一个相对独立的 setion，它们使用不同的数据进行渲染。在代码组织上，这些部分也是属于不同的 view 文件来负责。
4 的部分就是我们所说的，可以通过过期时间来管理的片段。这个部分 10 分钟更新一次没有问题。
3 的部分类似上面 markdown 的例子，渲染是耗时的，而数据是经常不变的。所以我们可以通过类似 'user_profile' + user.id + user.updated_at 的 cache key 来将其缓存。
而 1 和 2 的部分，就类似上面【被动过期】的例子。1 中，不仅有帖子的标题，还有帖子的作者信息，还有帖子的最后回复者信息，粗略一算，这都是 3 条查询。如果能缓存起来，那是大大滴有用。而 2，包含了所有 1 类似的部分，也可以被缓存。但如果 1 动了，2 怎么办？所以在缓存 2 时，我们可以使用所有 1 中最新的那个帖子的更新时间来作为 key，当有帖子更新后，更新时间对不上，缓存就被动过期了。
如果是个大型站点，1 的内容频繁动，那么会导致 2 的缓存命中率很低。这时，从业务上，我们判断，主页的新鲜期是可以在 5s 内不变的。这时，缓存策略可以改为，最新的帖子的更新时间，如果离现在的时间不超过 5s，则返回之前缓存的内容。我们一下就从【被动过期】的策略，变回【过期时间】的策略了。
所以具体采用什么策略，根据业务场景可以灵活选择。
【被动过期】策略时，切记要让上层片段的缓存 key 可以被下层 touch 更新。【过期时间】策略时，需要我们判断一下内容的新鲜期。
并且有一点比较深入的知识点是，不同的 touch 策略，会对缓存命中率产生影响。这个知识点请参照本小节 resource 部分的链接去看看 Tower 在面对这个情况时的方案。
如果你要问我 CNode 在片段缓存上是怎么选择的，我可以负责任并潇洒地告诉你：目前没有这方面的缓存~~~~
说起来啊，一是访问量比较小，懒得做。二是，从技术上说，渲染是同步的，而在 Node.js 中，数据查询是异步的。我思考了一下，做这个片段缓存不是简单的事情。而 Rails 中做起来就简单多了，虽然玩 Node 的人总是觉得 Node 可以原生异步并发取数据是一件优越的事情。但同步 io 模型在这个地方带来的好处就是【惰性求值】 。Rails 在渲染时，可以判断一下到底是【查询 + 渲染】还是【直接取缓存】。而 Node 由于异步查询和同步渲染之间的冲突，要解决这个问题，必须有个方便地支持异步渲染的模板方案出现。
last_modified 和 etag
resource: http://robbinfan.com/blog/13/http-cache-implement
这节我们讨论的是静态页面在浏览器中的缓存思路。所以不是 max-age 和 cache-control 那套针对静态资源的方案，而是 last_modified 和 etag 这一套。
上面的内容，一直在说数据库，缓存数据库。但有一点不可忽视的是，浏览器中其实也缓存了我们页面的副本，这部分的缓存，也应该有效地利用起来。 最简单利用方式，就是让服务器判断一下最终页面生成的 etag 与浏览器 header 中传来的 etag 是否相同的，相同的话，则返回 304，省去网络传输的带宽开销。
注意，最简单的方式是判断最终内容生成的 etag！其实我们可以自定义 etag。在这里，etag 也可以理解成一定意义上上述的 cache key，只是这回，储存介质变成了用户的浏览器。
还是上面那个文章内容页面的例子，我们文章页面由 文章内容 + 评论 内容决定是否缓存。这时，我们可以把文章内容的更新时间和最新评论的更新时间拼成一个 etag，返回给用户。下次用户再访问时，如果 etag 对得上，服务端根本都不需要再去缓存数据库中取 HTML 片段数据，直接告诉用户一个 304，【内容与上次一样，没变化】。这时浏览器就直接从自己的缓存中取出页面进行展示了。既节省了宽带占用，又节省了查询开销。
etag as cookie
这里说点题外话，etag 在一定意义上是可以拿来当 cookie 用的。首先我们要了解，浏览器针对每一个 url（包括 querystring 部分）都可以存储一个 etag 值。
比如我是一个广告服务商，我的广告页面是 https://cnodejs.org/ads。每当不同的用户访问这个页面时，我都根据大数据黑魔法定位到这个匿名用户到底是谁，然后返回他感兴趣的内容。可如果用户禁用了 cookie 的话，我该怎么定位用户呢？这时候可以使用 etag。每当用户不带 etag 访问时，都生成一个不冲突的 etag 给它，那么下次他再访问我 url 时，etag 就回来了。
OK，结束了，结尾语是：Rails 社区代表 Web 开发世界的最先进生产力。
渲染是同步的，而在 Node.js 中，数据查询是异步的。我思考了一下，做这个片段缓存不是简单的事情。而 Rails 中做起来就简单多了
就算是异步，也是先取数据，后渲染啊！！！
用的ejs的话，给 partial 里加一层cache 就可以
有兴趣的话可以看看这个叫 TinyLiquid 的模板引擎，使用 Liquid 语法，支持在模板内调用异步函数，支持 include 和 extends 语法 1、项目主页：https://github.com/leizongmin/tinyliquid 2、在Express中使用TinyLiqui的：https://github.com/leizongmin/express-liquid 3、与ejs的使用对比：https://github.com/leizongmin/gz-nodeparty-201412-tinyliquid 4、Liquid语法参考：http://liquidmarkup.org/
Q & A
1、什么叫『支持在模板内调用异步函数』？
比如模板中 {{user_id|get_user_display_name}} 表示执行函数 get_user_display_name(user_id) 并输出结果（类似于ejs中的<%= get_user_display_name(user_id) %>，而在TinyLiquid中，get_user_display_name() 这个函数可以是一个异步函数，它的定义可能是这样的：
function get_user_display_name (user_id, callback) {
// 这里进行异步数据查询，查询完成后通过callback()返回结果
callback(null, display_name);
}
只要在初始化TinyLiquid模板引擎时使用一定的方法注册了这个函数，那么在模板里面使用是不需要区分是同步还是异步的，完全有模板引擎解决。
2、『include』和『extends』语法分别有什么功能？
include表示包含某个模板文件，比如 {% include "header" %}表示把header这个模板插入到当前位置；
extends表示将当前模板插入到某个主模板里面，比如{% extends "main" %}表示把当前模板放入main模板的指定位置
3、TinyLiquid为何能做到支持异步？
因为它把模板编译成了一种中间码，渲染的时候实际上是在解释执行这些中间码，所以它不受同步还是异步的影响。
4、TinyLiquid这种渲染机制运行效率如何？
不算很慢，一般的渲染速度比ejs慢三倍，但是它提供了更强大的功能，值。
https://github.com/coordcn/sml 类jade模板，半成品。最近没时间搞了。
渲染同步问题估计是不可避免的，顶多通过缓存渲染结果来改善，或者干脆给数据，让客户端渲染。
这个东西只要这么思考，渲染就是字符串拼装，那么自然就是消耗CPU周期，那么在哪个阶段消耗其实都是要消耗的，在总体上，不会因为异步而获得好处，异步本质上是事情让别人做，在等待结果的时候让出CPU做其他事情。异步渲染，顶多能实现让CPU负责渲染，渲染结果再由处理网络的CPU发送。但是这个过程还是有通信损耗的，不及缓存和客户端渲染来得实在爽快。
robbin 那个 orm 与 join 之间的下的结论是有偏差的
orm 和 mysql join 的复杂度其实是差不多的
mysql join 内部实现也是基于 buffer pool 缓存的
mysql 把buffer pool开大点，效果是一样的
而造成全表扫描的唯一可能就是SQL写搓了，没用索引
这个sql好解决，ORM遇到此问题就除非你真的精通ORM实现。。。
mysql join 与 ORM with cache 之间的另外一个区别就是 mysql 的 RTT 少，就一个来回就解决了，而 ORM 那种就 n+1 了，并发吞吐就地了
总的来说 SQL 全集，ORM 子集
@alsotang
有sql语句级别的 sql query cache
buffer pool 实现是基于页的，页miss才会从磁盘读取，而一般优化 页会预读的，页其实就相当于内存缓存
因此如果一个数据库的数据能在内存中存下，那么就没必要用redis这种cache
mysql innodb 的表是b+tree索引表，select join 查询的时候，还是会一个个遍历的(快慢就在于使用了索引遍历还是全表遍历)
关系型数据库操作的集合操作，join 其实就是做了笛卡尔积，最后还是会归结于一个个找的，先找内存，然后去磁盘
