Cache的选择以及特性建议

你可能没有明白我的意思。

这么说吧：比方，论坛中，post和thread的关系，我发了一个新的post(回帖)，那么这个post所在thread的cache就需要更新，否则thread显示的最后回帖时间就不对了。我们可以说，在cache这个意义上，thread对post有依赖。

那么，在系统的某个层次中就可能存在这样的逻辑：

postCache.remove(postKey);; // rpc
threadCache.remove(threadKey);; // rpc
// otherCache.remove(otherKey);; // rpc

注意，postCache和threadCache是cache的两个region，也可以认为这是两个不同的cache，上面说的依赖，就是要在更新一个cache的时候，自动去触发对另外一个的更新。

这个逻辑当然不应该属于cache，因为对cache来说，它只要扮演好自己“put什么进去就get什么回来”的职责就好了。那么，在建立depends关系之后，cache的客户端代码简化为：

postCache.remove(postKey);; // rpc

而在cache的内部的某个层次上，在接收到remove事件的时候，自动去“通知”其他“关注”这个事件的cache region，并在本地执行remove动作。

如果你不把上面红色部分代码，都放到Cache内部，代码必然会重复。

我会这样做：
不管是local还是Remoting的Cache。通通当作Remoting的来处理，都发出postCache.remove(postKey) 的消息。各Cache根据配置来决定该remove掉那些内容。

我们说的是同一个意思，回帖操作的时候，在网络上broadcast的只有这一条postCache.remove(postKey)消息。各个cache根据配置在本地localRemove相关联的其他对象的cache。

虽然我也认为这个“消息处理机制”应该放到cache内部，但我倾向于认为，这是cache通过配置文件来“帮助应用维护对象之间的依赖关系”。

既然是“帮助”，那就是可帮可不帮，换句话说，如过我来做这件事，那是我帮你做了这些工作，我如果不做，那你还不是要在代码之中老老实实的多次remove，通过多个remote的调用来同步cache？

也许是我孤陋寡闻，研究得不够透彻，可是我现在并没有看到哪个cache已经支持了这样的特性。

这更像是sugar，而不是feature。它只是方便了cache客户端代码的编写节约了几次RPC，毕竟，市面上n多的cache没有这种能力，它们还不是一样运转良好？

我倒是觉得center的cache也需要考虑实现这样的特性，尽量减少remote remove数量之余，也简化client代码的编写。

我不认为remove时同时“帮助应用维护对象之间的依赖关系”属于cache机制内部的事情。比如hibernate，他只需要cacheprovider提供特定、简单接口的cache。而remove po时“帮助应用维护对象之间的依赖关系”是hibernate自己处理的。

想想，本机的Cache，是通过多次调用remove来避免脏读的。Remoting的Cache是通过配置文件来管理依赖关系，避免脏读的。两者职责完全相同，却有两份代码，这意味着可能产生不一致的严重后果。不该把它们合并么？
所以，要不都采用多次remove的方式，要不都采用配置文件的方式。没理由两种都存在的。考虑到网络开销，选择配置的方式性能应该更好些。

同意无明：

不能把cache当成DB来使，cache server 倒掉，最大的影响是性能会差点。

确实不属于，所以我说这是一个sugar，是“cache帮应用做的事情”。

应用本来需要remove多次，以及需要自己处理依赖关系，那么我现在提供一种sugar option，应用的代码可以改成只remove一次，cache在本地通过配置帮助应用remove其他对象，这么做的目的是为了“节约cache同步的rpc开销”以及“简化应用的代码”。

这只是sugar option，不强制，你要嫌配置文件麻烦或者逻辑不清晰，当然也可不用这个sugar，继续沿用多次remove的方式来同步cache。



两个并存当然就乱掉了，我有说过要两个并存吗？



你说得很对，cache只应该是优化，而不应该成为“关键服务”。但是，访问量这件事，有可能让cache成为一个服务之中的关键环节。

例子可能确实极端了些，不过，设想一下，比如，你的系统是象网易通行证这样的系统，在高峰时，每秒钟必须处理几万次的验证请求，此时，如果cache倒掉，你的db(几亿条数据的表)如何才能撑住这样的负荷？

如果是对性能那么要求严苛的系统,那么设计上肯定得对系统做很多特殊的优化了,那也不单单是一个cache的问题.我也没有这方面的经验,所以也说不上什么

但是如果系统压力大到,中心server模式都无法应付,那么,毫无疑问,这时应该考虑使用分布式的模式(中心cache server分布也是可以的),但是这样的讨论似乎意义不大,robbin有句话说的很对(原话我忘了怎么说的),真的有这么迫切的要求时候,应该也有相应的资源投进去解决这个问题.

rails的缓存机制就设计的很灵活,研究一下这个我觉得比研究那些极端的系统更有借鉴意义.

同意啊。万恶的资本家，又想马儿不吃草，又想马儿快快跑。TNND。等咱有钱了，就整它十台服务器，一台跑应用，九台做缓存。闲死它。

交换机FAIL的组网可能性还是有的，所以现在电信应用都是双平面设计。就连F5都需要1+1备份的。

memecached的failover的可能性还是必需要考虑的，不然可不敢使用。