主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊
家园 本质区别是应用层次的不同 一个网页代表一个完整的应用，memcached存储的只是代表一对象
有是有一个应用只固定引用一个对象，有时候一个应用和对象的关系可能是随着时间、访问者的变化而不一样
而且memcached对象可能在相当长的一段时间内是持久化的
而用反向代理缓存的页面可能是有一定时限的
当然既然是缓存，那么就不存在特别本质的区别。
家园 memcache主要是消除高并发下DISK IO的瓶颈 memcache的理论出发点是在数据库高并发而且无序访问下，因为有限的数据库内存缓存无法缓存全部记录，数据库将不得不进行大量的DISK I/O读写，而memcache是基于内存的，因而速度会快的多。
replicate server是可以分担一部分压力，但是随着交易的进一步增加，master和replicate server之间的同步又会造成新的DISK I/O瓶颈，因而在更新较多的环境下，一台master能带的replicate server的数量是有限的.而memcache由于是分布的，扩展性比replication server要好很多。
很多大的网站都是replication+memcache两者相结合，两者各有各的用处。自我广告一下，可以参见本人关于Flickr的案例研究以及跟帖和讨论。
家园 其实如果数据库内存够大 是不是就不需要memcache了？
这个就跟具体应用有关了
拿memcache缓存二次运算结果，这个结果相当长时间那固定，但是比数据库来说可能又不是那么持久，这个适合在memcache缓存
1.完全持久化直接用数据库（经常需要写操作的，例如统计数据，用户活动信息等）
2.二次相对固定运算结果用memcache（比如具体文章内容、文章的状态这种可能很长时间不会修改的）
3.短时间内固定用apache反向代理缓存（比如首页这种一天变一次的）
家园 如果数据库内存足够大，memcache的优势就不明显了 事实上现在至少IBM和Oracle都已经推出了IMDB产品 即(In memory Database),将来的趋势看起来是全部Runtime数据都在内存里，硬盘只作为永久保存。Memcache的将来还很难说。
家园 不见得 memcached可以承受非常高的并发访问，这方面数据库是弱项。
家园 In memory Database和memcache 这个怎么用memcache或者In memory Database和应用的设计有很大关系，不是说一切都要缓存，缓存了一定就快
比如全文检索的结果，缓存有多大意义？
比如我们常用的查机票，这种多条件复杂查询的结果用memcache这种key-value结构的缓存意义不大。
我没怎么研究过In memory database，估计In memory Database的结构和memcache结构差异主要还是在in memory database更多是可以支持复杂的排序 order之类的，可能更多会用到Tree结构去存放数据
家园 In memory database就是全部数据都在内存 绝大多数操作也在内存，这已经不是通常意义的缓存了。现在TB的内存已经不少见了，in-memory Data Grids技术的运用使得将全部数据读入内存在不久的将来成为可能,无论无何内存的读写比硬盘要快至少一个数量级。
相比之下，memcache只是key-value,不支持sql语句。两者不可同日而语。
推荐一篇文章 http://natishalom.typepad.com/nati_shaloms_blog/2008/03/scaling-out-mys.html
唉，好象歪楼了。
家园 老铁的问题很关键，其实cache这个词，简直就是词不达意 老实说，网站大了，开始接触缓存，痛苦就开始了，首先，“缓存”，这两个字太混乱了，就应该像古时候一样，骒、驹、骟、骠、骝、骃、骅、骊、騧、骐、骢、驽、骁、駹、骍、骥之类的分清楚，什么玩意儿都是缓存二字了之，汉语不清楚咱们看英文吧，好么，cache，还是一个字儿，当初羊可没少抓头皮。
从request到达开始，网站一通忙活，这中间缓存（cache）其实各得其所，都不是一码事
只能延着代码向数据库的方向，一层一层往下梳理
首先是各式各样的reverse proxy（这个不叫cache，可是很多哥们儿习惯上还是叫他缓存。。。这不是添乱么），这东西其实和程序关系不大，和网站是松耦合的，其实要说不耦合也行，它其实就是代替用户访问网站，然后把访问结果找个地方存着，下次再有人要同样的东西，就直接拿出去，省的再让网站程序忙活了。
然后是apc，这个是代码cache，主要作用是缓存字节码，代码运行的时候总要编译或者解释，apc把这个二进制的字节码放在内存里，下次执行的时候，直接拿出来用就得了，这能节省一部分时间，一般业界的经验，会有2-10倍的提升，很可观了，最好的是APC部署很容易，装上，改一下php配置文件就得。不过话说回来了，代码跑得再快，还得看后端数据库，如果数据读取很慢，代码跑得飞起来，也是白搭。另外apc也有很简单的在内存中保存数据的能力，确实有点像memcached，也是读写key->value，像倒是像了，毛病也全都有了，而且好像这个功能用的人不多，大伙儿还是更关注apc缓存字节码的能力，所以能不能达到memcached的好处，就不太清楚了。
在接下来，程序要获取数据了，memcached出场了，这个就不多说了，之前帖子里头说的不少了，老铁对于memcached的理解，尤其是对于减轻并发冲突的见解，正中要害，能否用数据库的复制解决并发问题，从我的个人经验来看，有用处，但用处不特别大，但是很多文档却对数据库复制解决读写并发冲突推崇有加，这中间估计应该有我不了解的妙处，所以不敢置喙。
说说我经历过的一个项目，用的sql server ，因为系统查询负载很大，所以做了一个专用的查询服务器，数据从业务服务器发布过来，结果是查询的速度有提升，但是跟数据库发布关系不大，因为实际上发布动作也还是不断的在写入数据，读写冲突仍然存在，查询速度的提升更像是跟单独服务器计算资源比较丰富有关。至于业务操作，倒是有提升，这个就跟读写冲突有关了，业务服务器上在也没有大量的纯查询操作了，写操作完全独占，效率大大提升。
memcached，也可以看成数据库发布到内存里面了，那么，在效率方面的变化其实和上面的例子有异曲同工之处，而且，由于内存在速度方面的先天优势，所以在读写方面的提升都很显著。当然，要说数据库的复制，虽然速度慢点，也有独特的好处，数据库的复制在部署的时候和代码是松耦合的，如果规划的好，完全可以做到代码无关，而memcached就不行，部署的复杂度方面，天生比memcached有优势，所以，很多时候，碰到读写冲突的性能问题，一般而言，我会先拆了数据库，个别时候甚至为了不动代码，干脆使用内存表，如果结果还不行，才考虑memcached。
家园 我赞同你的观点 一般而言，我会先拆了数据库，个别时候甚至为了不动代码，干脆使用内存表，如果结果还不行，才考虑memcached。就我的经验而言，也是这个比较好。首先在应用上优化，然后才是cache的优化。
家园 对memcache的解释很清楚，花。 家园 先占位,回头再补花 羊倌好老实啊....这么乖..不挖坑,填料填的都是静悄悄的
模范标兵
要继续向老邓学习啊.
争取早日成信息技术栏目的劳模.
家园 愤怒的上花~~~ 调皮的丫头，刨坑都刨出花儿了~~~
唉我真是老了。。。
家园 什么时候写完？写完后搞个PDF合集，方便反复阅读。 这个系列不是一篇可以领悟的，需要反复看。
反复看的东西，最好有个打印件，躺在床上，站着等地铁，蹲在某处，等等场合，都方便阅读才好。