主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊
连转给老邓这么重要的事情都忘记呢,已经转给他呢,楼上的大佬您听好嘞,查邮箱.密码在大家常玩的那地头儿.实在是发的时候忘记呢有人还设计呢这么个陷阱,声讨之...
不就是土鳖版嘛,嘿嘿.我才没有看的头疼.嘻嘻.因为没看..
偶是邪恶的小山子,可不是自讨苦吃的小山子.
我的GFS那一篇，WebOS那一篇都是烂尾。
GFS的原因是写着写着，觉得写作方法有问题，再这么写下去，会把读者枯燥死。
WebOS写着写着，觉得Palm再不投降Android就没戏了。写一个行将就木的东东，着实无精打采。
不知道新年来临，是否有信心重拾旧河山，给烂尾们一个妥善结局。
这个是我没弄明白的事情，也是工作中印证的问题。
在CPU的cache机制里面，cache能够起作用，关键在于对代码和数据的访问的locality。说白了就是在未来的一段时间里，有非常大的可能，去访问过去一段时间访问过的代码或者数据。
这个locality和互联网的长尾是根本对立的。长尾是说，这个世界上什么人都有，什么品味都有，有喜欢山珍的，也有喜欢臭豆腐的；有用银餐具的，有吃手抓饭的；最要命的是，喜欢臭豆腐的720个人里面，有两个是把臭豆腐直接吃下去的，有两个是喜欢转1°然后吃，有另外两个是喜欢转2°吃下去...
于是cache就很命苦，刚记下，说客户喜欢转1°吃臭豆腐，接着就要记转2°的，直到最后忘记了，客户过来说：喂，我上次说我喜欢转1°再吃的？
现在，memcached几乎成了网站标配的东西，无论什么网站，一旦性能出了问题，首先想的几乎都是“我是不是要上个memcached？”
现在玩儿php的多，flickr，wikipedia都是基于php的，咱们就拿php说事儿，这种cache偏执症，小羊接触过十个用php的其中就有八个，而且这八个当中还真没有多少实际在项目当中用过cache，反倒是玩儿java或者python，ruby这些动态语言的哥们儿，cache对于他们几乎就是常态，用的多了，倒对于cache有不同的看法，那就是——没比有好，少比多好。
先前有朋友的回帖中，已经看出了性能报告显示的问题，我们延展开来先吹吹cache的冷风。
关于memcached，有两个通常的误解，第一，应用cache是很方便的，第二，无论怎么说，cache总是比数据库要快，我们就从这两个方面说起。
一、memcached不是数据库，它和数据库在使用上的区别就好像BASIC的文件操作和C语言的指针，memcached实际上是一个大的内存hash，所有的读写都是在操作key=>value对，换句话说，需要得到一个value，必须明确知道其对应的key，一个习惯了select,insert,update,delete的程序员在第一眼面对memcached的时候都会非常不适应。毫无疑问，应用memcached会带来代码层面的改动，所以，混乱的代码和对于应用memcached不充分的前期准备都会使这项改动代码的工作成为噩梦。就算是在访问层面跨过了这一关，后头还有一个缓存和数据库同步的问题在等着你，“脏数据”，这个通常被RDBMS处理掉的问题，现在需要程序员自己操作了。
另外，小羊接触的很多对memcached满怀憧憬的哥们儿都有一个普遍的误解，那就是几乎所有memcached介绍文章都会提到的的“分布式”，好像这下子程序可以无限制的水平扩展下去了，实际上，memcached本身恰恰是不具备分布式能力的，甚至多个memcached多个节点之间无通讯还是它的一个卖点。所谓分布，是由memcached的接口函数实现的，多了这么一个接口程序，又是一个复杂度的上升，而且还有函数库本身效率出现问题的风险。
二、应用cache一定很快么？先考虑读取数据的问题，对于简单的查询，memcached的操作速度通常和经过良好优化的数据库一样快，select a from b where x=y 的操作数据库花不了1ms的时间，memcached也快不到哪儿去。如果碰到缓存没有命中，那么仍然需要访问数据库，说不定还要把访问结果写入缓存，那么花费的代价则是数据库的至少两倍。
假设缓存总是命中，那么从速度上面看，查询越是复杂，memcached的优势越大，因为我们会在memcached中仅仅存放查询结果，而数据库则要稀里哗啦把N个表折腾一下。但是慢着，我们好像在讨论复杂查询结果放入缓存的问题，那么首先看看所谓的“复杂查询”，如果需要把一个“复杂查询”的结果放入缓存，那么意味着这个复杂查询的访问频率相当的高，否则我们只能得到低下的“缓存命中率”了，考虑到应用memcached带来的代码、架构以及维护的复杂度上升，低下的“缓存命中率”几乎等于得不偿失。如果缓存命中率很高，您的应用需要频繁的使用这么复杂的查询，那么也许首先要做的不是考虑memcached，而是检讨一下整个系统包括数据库结构的设计了。假如在信息版回帖，西西河的程序需要先要动用一个关联N张表的复杂查询，判断一下经验、声望、乐善、是否认证...这样...绝大多数不明真相的河友面对一页页500错误一定义愤填膺，那样会让GFW蒙受不白之冤，亲者痛仇者快阿~~最重要的是：如果这样的代码是小羊写的，那么老铁一定不给工钱，小羊只好过年的时候去爬脚手架了。
除了读数据，还有写数据的问题，通常，为解决缓存和数据库同步问题，可以有两种方法，第一种是从数据库读出数据后，写入缓存，以后直接读缓存，这是一个常见的说法，长野雅广、前坂徹在广为传播的《memcachedを知り尽くす》一文中开篇说的就是它。第二种方法是在写数据的时候同时写入缓存，读的时候直接读缓存。无论哪种方法，如果数据经常被访问，那么我们两次的辛苦也就罢了，如果访问率很低。。。嘿嘿，反正内存便宜，希望大家都可以不用关注成本问题而且收入和代码行数挂钩。
罗罗嗦嗦说了这么多，memcached还真是麻烦阿。没错，这就是开篇所说的——在性能没有问题的情况下，cache，没比有好，少比多好。
如果读到这儿，您认为memcached能存在到今天都是错误的话，那么，小羊首先要道歉，这不是小羊的本意。memcachd其实真的是好东西，只不过，使用的难度很大，也很考程序员和架构师的功力，明确了这一点，在回头看看wikipedia，才会理解wikipeida在使用memcached上的精要之处。
喝水
羊倌好老实啊....这么乖..不挖坑,填料填的都是静悄悄的
模范标兵
要继续向老邓学习啊.
争取早日成信息技术栏目的劳模.
调皮的丫头，刨坑都刨出花儿了~~~
唉我真是老了。。。
你的这个，西电鲁丁的那个，还有邓侃的那个俺都读了，要说俺看后记住了什么 ------ NOTHING。你说俺这人是不是愚笨了些？
没记住东西不等于没有印象，哪怕是个错误的印象。
这个印象就是这些"大集群"的架构师也就一民工包工头的水平，天天的任务就是头疼医头，脚疼医脚。什么地方出问题（就是鬼子喜欢说的BOTTLE NECK）了，然后就在那里放个性能监测器，把那个“瓶颈”进行动作分解（1，2，3....7.8）。如果3这一步最费资源，能不能把3独立出来用单独的服务器运行，更进一步能不能用一组服务器运行，如何在这一组服务器内进行3的“负载分配”。如此往复，天长日久，于是他们的“功力”见长。
见笑咯见笑咯，俺陪兄弟玩一会。
不过你那个08-09财年报告很好，俺写financial projection的时候从里面推测了好几个数据。谢了。
说道根儿上，太守说的没错
在详细说么。。。回头再说，喝水
好友居然可以被屏蔽？好友为什么被屏蔽？
之前找过一点东西看，看的云里雾里，不知道它到底好在哪里，到底不好在哪里。
按照我的理解，它的主要目的，应该是为了减轻数据库的负担。主要的方式，就是把后台数据库的内容搬一些到前台来，如果前台能够满足需求，后台的操作就会大幅度减少。数据库的操作所对应的负荷，可能还不只是数据库设计的问题，更主要是因为读写操作一多，并发的问题就比较突出一些。
memcached 至少可以大幅减少读操作。可是如果这样的话，就有人建议用数据库的 replicate 来分布读操作。
如果是用 php ，那么用 apc 是不是和 memcached 本质上可以达到一样的效果？
和那些 reverse proxy 又有什么本质上的区别？还是只是缓存的级别不同，一个是部分内容，一个是整个网页？
老实说，网站大了，开始接触缓存，痛苦就开始了，首先，“缓存”，这两个字太混乱了，就应该像古时候一样，骒、驹、骟、骠、骝、骃、骅、骊、騧、骐、骢、驽、骁、駹、骍、骥之类的分清楚，什么玩意儿都是缓存二字了之，汉语不清楚咱们看英文吧，好么，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。