其实像你那种博客，可以采用 FileStore 的，或者用 caches_page，直接缓存为静态 HTML 文件

1. 可以，甚至页面缓存
2. 都可以设置最大内存占用

明白了。谢谢两位

保存 post 可以把 markdown 和转换后的 html 同时存在数据库里，没必要这么做缓存吧。。。

#4 楼 @paranoyang 我不太清楚什么时候不应该做缓存。。我现在的理念是能缓存的都缓存。。 全都缓存了不用读数据库不是更好吗？（疑问句，不是反问句） 有没有什么情况不适合做缓存？

条件允许的话用 redis 或者 memcached 比较好，用数据库字段缓存意义不大。像现在的一条回复，不单是文本的格式处理重复耗时，而且 user 信息的读取还会导致 1 + N 查询，另外还有 @ mention 的查询。这时候最好的方案就用片段缓存，把一条回复片段 cache 起来，这样一来数据库里面做缓存做优化就失去作用了。所以说缓存要后加，找到瓶颈才出手。

另一种思路是对象缓存，在 ITeye 大量使用。比如 User.find id，这种调用都是从 memcached 获取对象的，好处是缓存一次，到处调用。Twitter 放出的资料来看也是偏向这种，行缓存（数据）+ 列缓存（timeline)+片段缓存

#6 楼 @Rei 1 + N 查询可以通过 eager_loading 和 idendity_map 来避免其实。并非一定要缓存 同意缓存要后加~ 关键是的确有性能问题，才需要缓存，具体可以 benchmark 看一下

楼主应该是为了练习目的加的缓存，这样你可以试试几种不同的方式的缓存，对比下几种模式各自的利弊，这样更容易理解。

ps @Rei 报告 bug 一枚 修改回帖出来的 flash message 好像还是 "删除成功".

#8 楼 @aNdReW_Qx idendity_map 是同一对话内有效，存到外部的 cache 就可以各个会话共享（这时候对象序列化速度有可能成为瓶颈）。

#9 楼 @Rei 这倒是 , 不过缓存说到底，空间换速度，如果不用缓存也抗的住的话就尽量少用缓存吧

#10 楼 @aNdReW_Qx 赞同。过早使用缓存会得不偿失，比如——在这个加个 xx 功能吧？不行，这样缓存就失效了/要重大修改，那还是放到别的地方吧或者不要提供了——这种情况出现。