主题：谈谈大型网站架构的一些关键技术 -- 季侯

应该说是牺牲一点更新的效率，换取查询的效率。我帖子里提到的就是这个

事实上，作为一线程序员我们的感觉这是以模块的耦合度换取查询效率，这样做的一个后果是更新功能和查询功能耦合在一起了。这就是架构师和程序员的矛盾之一。

我们换一个例子，就以西西河为例。页面上有好几个帖子列表，如果这些列表有些需要缓存的话，那么发帖和回帖的功能就必须相应地更新这些缓存项。有时候不一定能准确推算出应该更新什么，比如热门贴之类的东西（你必须重新查一次才知道热门的变更）。

再比如：复合条件查询结果，车票这个相对简单我们只使用了起止站点，如果把那个实际页面的查询条件加进来。缓存方法就需要另外设计，比如我们只用起止站点做查询，然后在结果中自己根据其他条件做筛选。否则在主动更新的时候，条件组合会很多。并且更改查询需求就会同时变更修改的代码。

还有一个类似的例子就是分页显示，缓存什么、怎么更新就是一个很值得讨论的问题。

综上所述，并不是任何时候都能用推的方式。

我经手的一个客户就是这种情况，他们使用的是定期失效的方式被动更新缓存，结果就遇到那种随机的查询爆发。

使用另外的机制主动更新缓存也是一个解决方法，不过这些都说明使用好缓存都需要付出一些代价。我一般会倾向于先发掘现有的代码（包括数据库）的潜能，因为模块耦合度在项目后期是所有人都要头疼的事情。

所以Cache可以用，但要清楚付出的是什么，这可不是一手交钱一手交货的买卖，有时候它更像一个驴打滚的账单