主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊

就我的经验而言，也是这个比较好。首先在应用上优化，然后才是cache的优化。

只有定位了问题才能解决问题。

1，有性能检测或者调试日志。

2，在此技术上的单步跟踪和压力测试。

一般能够解决大量性能问题。

memcache的理论出发点是在数据库高并发而且无序访问下，因为有限的数据库内存缓存无法缓存全部记录，数据库将不得不进行大量的DISK I/O读写，而memcache是基于内存的，因而速度会快的多。

replicate server是可以分担一部分压力，但是随着交易的进一步增加，master和replicate server之间的同步又会造成新的DISK I/O瓶颈，因而在更新较多的环境下，一台master能带的replicate server的数量是有限的.而memcache由于是分布的，扩展性比replication server要好很多。

很多大的网站都是replication+memcache两者相结合，两者各有各的用处。自我广告一下，可以参见本人关于Flickr的案例研究以及跟帖和讨论。

在我的理解和经验里面，常用的场景是对象缓存。java下面的开发的一个潮流和趋势是数据的对象化，由框架实现对象和数据库表的映射关系（当然直接用sql从表读取数据也是常见）。这时常见的性能瓶颈都会出现在从表读取数据映射到对象上以及对象保持到数据库的时候。

通过map方式缓存已读取出来的对象，对于会频繁读而少写的对象，缓存此时会起到很大的作用。可以看到memcached的缓存和java的这个缓存模式基本是一致的。

一个网页代表一个完整的应用，memcached存储的只是代表一对象

有是有一个应用只固定引用一个对象，有时候一个应用和对象的关系可能是随着时间、访问者的变化而不一样

而且memcached对象可能在相当长的一段时间内是持久化的

而用反向代理缓存的页面可能是有一定时限的

当然既然是缓存，那么就不存在特别本质的区别。

是不是就不需要memcache了？

这个就跟具体应用有关了

拿memcache缓存二次运算结果，这个结果相当长时间那固定，但是比数据库来说可能又不是那么持久，这个适合在memcache缓存

1.完全持久化直接用数据库（经常需要写操作的，例如统计数据，用户活动信息等）

2.二次相对固定运算结果用memcache（比如具体文章内容、文章的状态这种可能很长时间不会修改的）

3.短时间内固定用apache反向代理缓存（比如首页这种一天变一次的）

事实上现在至少IBM和Oracle都已经推出了IMDB产品 即(In memory Database),将来的趋势看起来是全部Runtime数据都在内存里，硬盘只作为永久保存。Memcache的将来还很难说。

这个怎么用memcache或者In memory Database和应用的设计有很大关系，不是说一切都要缓存，缓存了一定就快

比如全文检索的结果，缓存有多大意义？

比如我们常用的查机票，这种多条件复杂查询的结果用memcache这种key-value结构的缓存意义不大。

我没怎么研究过In memory database，估计In memory Database的结构和memcache结构差异主要还是在in memory database更多是可以支持复杂的排序 order之类的，可能更多会用到Tree结构去存放数据

绝大多数操作也在内存，这已经不是通常意义的缓存了。现在TB的内存已经不少见了，in-memory Data Grids技术的运用使得将全部数据读入内存在不久的将来成为可能,无论无何内存的读写比硬盘要快至少一个数量级。

相比之下，memcache只是key-value,不支持sql语句。两者不可同日而语。

推荐一篇文章 http://natishalom.typepad.com/nati_shaloms_blog/2008/03/scaling-out-mys.html

唉，好象歪楼了。

我是做java的，各种数据库持久层的cache倒是常用，用与不用确实相差很多

有时为了比较好的用户体验和降低数据库的IO操作也常用cache，将各种常用的数据放入cache中，实现数据库只写，cache只读，cache定时与数据库进行同步。

不过比较复杂的问题是cache做分布不大好做，碰到前端应用做了集群cache再去做集群就不大好扩充了。。

现在我更多的是使用内存数据库H2，性能比MYSQL的内存数据库好，还不要钱，是个好东西

memcached的主要目的是为了缓解数据库的压力。

先说个题外话，mysql的创始人在离开sun之后又新搞了个数据库，叫啥名字忘记了。这个数据库里面没有query cache，据他自己说法是这部分交给memcached了。

这可以说明，memcached很像db的query cache，但是又有些优势。是什么优势呢？我想主要是：

1. query cache是以sql做key的，非常不灵活，提高命中率比较难

2. query cache不够大。mysql的query cache缺省是16M，太小了。

3. memcached在应用和部署上都更灵活，更适合高并发访问。

由于memcachd是key->value的存储模式，跟db的sql有很大的不同，所以在应用的时候，最好是用key/value模式重构数据模型。这样memcached就不是简单的存储sql查询的结果，从而有效提高存储和使用的效率。

当使用replicate来分布读操作时，写操作一般都是在master上完成。这种模式下还是需要应用程序进行修改，严格区分读写请求。实际跟使用memcached的工作量差不多。而memcached相比从数据库而言要轻量多了。

这是一个不同之处。并且reverse proxy不一定是完全基于内存的，还是有可能发生io。本质不同应该是memcached可以存的东西远远不止网页，事实上可以是任何东西。

我也是这种感觉。数据库层面上的缓存实在是比较低效。按文档的意思，一旦表内容有改变，缓存就要作废。但是从 memcached 的实施来看，可以短时期内不必在意有些改变，比如拿西西河来说，可以在短期内不必在意点击数量的改变。单单这样估计就可以提高不少效率。

考虑到replicate，主要是兼具了数据库备份的好处。

memcached可以承受非常高的并发访问，这方面数据库是弱项。

使用cache当然需要有前提条件，当符合条件时，cache就是有比没好，多比少好了。

例如文中提到的memcached实际是个write through的cache，当读访问远远多于写访问，并且读的内容比较集中时，用它可以大大降低数据库压力。

另外memcached的访问速度还是很快的，如果说db的速度通常在1ms的话，mc的速度基本上是在50us的水平。

除了访问速度快，mc还有一个优点是性能上限高。在现在的主流配置下，mc的访问性能可以达到100000qps以上。这对于web之类的应用是比较关键的。因为对于这些应用，所谓“性能不是问题”通常都是暂时的，可能中午不是问题，到了晚上访问量翻倍，db性能就是问题了。而如果有cache的保护，情况可能会好的多。