对于变化不太频繁的数据，大家都比较喜欢存Memcached以减少数据库的读取，但还是会有语言解析运行上的消耗（比如运行PHP，Python等），当然这个时间很短，记得OP上有个同学说P字头的语言，效率都不高，如果能省去，当然最好。（已经用上Squid等的可以忽略本文）。

还有一个问题就是很多时候一个页面由多个数据片断组成，为了提高页面速度，要么分别缓存，要么整体缓存（所谓的Page Cache），其实都比较麻烦，增加和减少数据片断的时，大多需要调整。

最后一个问题，所有的数据都存Memcached是否经济？服务器资源足够多的无所谓，捉襟见肘的就要考虑了，当然，生成静态页面是一种方法，需要维护，还是比较累。

好吧，nginx的fastcgi_cache可以解决上面的那些问题，比较squid等的好处是简单，不需再要去维护另外一个系统，适合不那么大的网站。

关于Nginx fastcgi_cache，基础的可以参看Nginx官方文档http://wiki.nginx.org/HttpFcgiModule，下面是一个典型的做法是：

fastcgi_temp_path /data/ngx_fcgi_tmp;
fastcgi_cache_path /data/ngx_fcgi_cache levels=2:2 keys_zone=ngx_fcgi_cache:512m inactive=1d max_size=40g;
fastcgi_cache_valid 200 301 302 1d;
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_cache_key $request_method://$host$request_uri;

注意一定要加上$request_method作为cache key，否则如果HEAD类型的先请求会导致后面的GET请求返回为空，全局定义一个缓存空间，配置文件名为，fastcgi_cache.conf，然后在vhost配置里面加上：

fastcgi_cache ngx_fcgi_cache;
include fastcgi.conf;

大概解释下各个参数的含义：

fastcgi_temp_path：生成fastcgi_cache临时文件目录

fastcgi_cache_path：fastcgi_cache缓存目录，可以设置目录哈希层级，比如2:2会生成256*256个字目录，keys_zone是这个缓存空间的名字，cache是用多少内存（这样热门的内容nginx直接放内存，提高访问速度），inactive表示默认失效时间，max_size表示最多用多少硬盘空间，需要注意的是fastcgi_cache缓存是先写在fastcgi_temp_path再移到fastcgi_cache_path，所以这两个目录最好在同一个分区，从0.8.9之后可以在不同的分区，不过还是建议放同一分区。

fastcgi_cache_valid：定义哪些http头要缓存

fastcgi_cache_use_stale：定义哪些情况下用过期缓存

fastcgi_cache_key：定义fastcgi_cache的key，示例中就以请求的URI作为缓存的key，Nginx会取这个key的md5作为缓存文件，如果设置了缓存哈希目录，Nginx会从后往前取相应的位数做为目录。

fastcgi_cache：用哪个缓存空间

这样就可以了，基本上可以work，但还没完，如何手动清除缓存？有个Nginx的第三方扩展可帮你做到：https://github.com/FRiCKLE/ngx_cache_purge/，如果对大多数第三方扩展无爱，写个清除的脚本也非常简单，以PHP为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
function purgeCache()
{
    $url = $this->post('url');
 
    if (empty($url) || !Cola_Com_Validate::url($url)) {
        exit('请输入正确的URL。');
    }
 
    $md5 = md5($url);
    $cacheFile = $this->_cacheRoot . '/' . substr($md5, -2, 2) . '/' . substr($md5, -4, 2) . '/' . $md5;
 
    if (!file_exists($cacheFile)) {
        exit('缓存不存在。');
    }
 
    if (@unlink($cacheFile)) {
        echo '清除缓存成功。';
    } else {
        echo '清除缓存失败。';
    }
}

核心是第11行，直接找到缓存文件，然后删掉就可以，这个脚本有个副作用，手动清除之后，缓存失效，但Nginx后面还会自己清除一遍，然后报个unlink失败的日志，不过无关紧要了。

淡定，文章还没完，要不就成标题党了，Nginx fastcgi_cache缓存很不错，但我只想在某些页面用fastcgi_cache，很简单，有两种方法，一是在location中定义fastcgi_cache，这样只有满足一定规则的url才会用上cache，其他的就不会了;另外一种方法是在你不需要缓存的页面上，输出禁止缓存的头信息，用ColaPHP的话，直接$this->response->disableBrowserCache(); 具体代码：

header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

这样就告诉Nginx，这个页面不需要缓存。

好吧，要淡定不要D疼，还有最后一个问题，如果页面中只有一小部分内容不可以缓存，可以用Nginx fastcgi_cache吗？比如某个内容页，大部分内容可以缓存，但希望把用户的登录信息更新上去。答案是肯定的，可以直接输出用户未登录的页面样式，等页面加载完毕之后，通过ajax异步更新用户信息：

$().ready(function() {
    initUser();
})

码完收工。

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2009/01/cu-net-opt-salon/

特意把调休放在1.9，主要是想去听听CU组织的网络优化论坛，报名的时候有点意外，貌似丢失了报名信息，和组织者沟通了一下，感谢周平同学的热心帮助，说到的时候找他就可以，去的时候其实也没有查邀请函什么的，还给了件CU的T-Shirt，甚是感谢，一般这种开源技术研讨会都是很开放的。

首先是TOM网的曹刚带来的“浅析系统架构”，主要讲的是Myspace和SOHU社区架构的演变过程，基本的内容可以参考构建可扩展网络应用的七个步骤，一般他们的历程都是从第一步到第四步，大体上差不多，我这里列举这个关键词：

• 64位：Myspace为了让服务器管理更多的内容，操作系统由32位升级到64位，我们都知道32位的操作系统最多支持4G内存（当然有方法可以实现超过4G，不推荐。），64位操作系统理论上支持4G个G，估计我是看不到用完的那天，这里要注意的是32位操作系统下，一个处理器最多处理2G内存，所以如果是Memcached服务器，不要一个进程给超过2G内存，浪费。好的做法是多开几个服务，或者直接把Memcached服务器和APP服务器合二为一，很多公司都这样。
• 分表：论坛的特点是数据一般是按照板块分组，所以对于论坛这样的应用来说，最好是按照板块ID分表甚至分库分机器。
• 板块帖子列表页：论坛的特性是新帖子、新更新的帖子排在最前面，所以可能的情况是每次刷新的时候页面都在变，SOHU社区的做法是把板块新帖子保持在一个链表里面，链表的特点是插入和删除都很快，问题是查询的时候只能遍历。

  其实对于一个论坛板块来说，热门的帖子不会太多，估计大家也就翻前几页，大可以把这个数据放进缓存中，比如维护一个队列，最新的500个帖子ID，帖子Title，新帖子放在最前面，自动顶掉最后一个，大可以用数组而不用链表，虽然插入的时候慢点，读取的时候却不用遍历链表。

  对于跟帖数据，一般都是按照时间顺序排列，新增加的帖子自动在最后，压力不会很大。

• google去搜一下Carp算法，一致性哈希算法consistent hashing（可以参考http://tech.idv2.com/2008/08/17/memcached-pdf/），Amazon S3 环形算法（是不是就是consistent hashing?不知）。

曹刚最后做了个总结，个人觉得：熟悉业务需求应该是核心。

第二位演讲者是来自占座网的吴炳锡，讲的是LVS和Nginx的负载均衡，这块以前只是从资料上看过，接触比较少，不过炳锡的介绍深入浅出，以前觉得LVS晦涩难懂，不敢动手，听完之后无知者无畏了，有机会试试看去。其实很多事情都这样，看上去挺难，做起来就容易了，下面是几个关键字：

• DR模式：LVS有NAT、TUN、DR模式，推荐使用DR模式，更多的信息去google吧。
• LVS->Nginx->Squid：组合的模式，LVS是四层的转发，Nginx是七层的转发，可以支持URL规则的转发，组合起来用就可以随心所欲了。
• 性能：Nginx的性能和LVS NAT模式相当，都是很好的解决方案，熟悉哪个就用哪个吧，性能都不是问题。
• keepalived：LVS居家旅行、杀人灭口必配武器。
• 搜房网：搜房网前端采用LVS做负载均衡，中间用Nginx做URL负载均衡，动态的URL跳到App服务器，静态的URL跳转到Squid服务器。

第三位演讲者来自某个赞助商，感谢他们对活动的赞助，就不做广告了，一句话概括：适合钱多人傻。

第四位演讲者来自SOHU的MySQL DBA叶金荣，报告的内容网上大多有，这里也列出一些关键字：

• 发现问题：系统响应慢、load avg >=5、IO wait >= 10、swap使用情况、mysql status、mysql report、mysql 5.1 profline
• xfs：如果可能，mysql数据文件系统分区采用xfs，效果高30％～50％
• innodb_buffer_pool_size：如果是专用的数据库服务器，设定为内存的80％吧
• MyIsam适合低并发、低更新、高读取的需求，InnoDB适合高并发、高更新、高读取的需求，MyIsam读取的速度比InnoDB快许多。
• Explain：查询检查、查询优化
• 联合索引：貌似MySQL一次查询只用到一个索引，联合索引要注意先后顺序的问题，“左派”比较吃香。
• 字段按需配置，能用TinyINT的不用INT，字段越短越好，具体差别可以参见：http://chaoqun.17348.com/2008/11/mysql-data-types-int/
• 把大表拆成小表，如果表字段里面有Text，尽量拆开吧。
• 缩短事务周期
• 字符型的字段，最好采用前缀索引。
• 复杂的查询拆成小的简单的查询，比如用循环查询替代。这点不敢苟同，还是按照自己的业务测试一下吧。一条sql语句总比N条要快吧，除非有问题。
• left join：把条目数少的放左边，如果你了解left join的话，这个是肯定的。
• 实时备份：用slave做实时备份吧，一个slave就是一个备份。

第五个演讲最为精彩，走了的人实在可惜，掌声和笑声不断，田逸这个家伙说话太有意思的，有机会要认识一下。讲的是CDN方面的事情，关键字：策略，技术很重要，策略更重要。

昨天的网络优化论坛受益匪浅，演讲者都有丰富的经验，其实网站架构就那么点事情，多分享才能共同进步，不过从互动环节可以看出国内做技术的对这方面关注还是比较少，有些问题比较原始，多关注一些就不会那样了。

PS:报告盖茨：我上周四叛逃到Linux了。