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

老实说，网站大了，开始接触缓存，痛苦就开始了，首先，“缓存”，这两个字太混乱了，就应该像古时候一样，骒、驹、骟、骠、骝、骃、骅、骊、騧、骐、骢、驽、骁、駹、骍、骥之类的分清楚，什么玩意儿都是缓存二字了之，汉语不清楚咱们看英文吧，好么，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。