不再更新blogspot上的blog内容

由于blogspot一直受到GFW的封锁，blog更新和查看很不方便，现决定不再更新blogspot上的blog。

以后blog将在国内的cnblogs上更新，在这边只通过RSS方式聚合最后5篇文档。

新博客地址： www.blogjava.net/daviszhao

［转贴文章］关于云计算的五种观点

云计算就和每一个IT趋势一样，包括面向服务的架构（soa）和Web服务。我们谈论的是关于云计算方面的，也许指的并不是同一个基本概念。

　　我最近加入了一个关于云计算方面的LinkedIn/Google组织，它们中的一个成员发了这样的一个贴，这个贴看上去是如此的简单。问题就 是：云计算和我们所了解的网格计算到底有什么区别?我当然有我自己关于这个问题的答案，但是整个晚上，有很多的回复者涌入，并且创建了一个e-mail 链，提供了一些关于这个术语的细微差别。

　　我希望我不会因此被该组织剔除之外，但是我认为它们中的一些观点非常有意思，并且可以拿出来供大家思考。出于隐私的考虑，我不会把任何人的名字附上，并且我把其中的一些观点重新整理一下，主要是为了更加地清楚和适合于文章的长度。以下是五个关于云计算的主要观点：

　　1.厂商总是将新词汇的定义混淆化。

　　在我和其它人的观点中，云计算是不同于效用计算的，同时和网格计算也不太相同。

　　网格计算通常是指一个用于计算任务(比如图像处理)的资源池环境，而不是那些长时间运行的进程(比如一个网站或者邮件服务器)。

　　而效用计算通常是指一个用于掌握长时间运行进程的资源池环境，并且趋向于专注满足服务的级别，通过优化一定量的必要资源。

　　云计算在很多情况下是指网络上提供的不同种类的服务，这些服务可以在服务提供商的架构上(比如谷歌的Apps或者Amazon EC2或者Salesforce.com)的计算功能上所提供。一个云计算的环境可以运行在一个网格计算环境下，或者在一个效用计算环境下，但是对被服务 的用户来讲并不关心。

　　2.云计算 = 网格计算

　　工作的负载被送往那些包含指派主机以及工作从节点的IT架构上。那些主机控制资源分配到这些工作负载之上(有多少从节点运行并行的工作负载)。 这对于客户来讲是完全透明的，用户只是看到工作负载被指派到云/网格上，并且结果被返回给它们。而从节点可以是，当然也可以不是虚拟主机。

　　云计算 = 软件即服务。这是一个谷歌的apps模型，而apps就放在云中，比如Web的某些地方。

　　云计算 = 平台即服务。 这是Amazon EC2 et al的模型，在该模型中，一个外部的实体维护着IT架构(主/从)，并且客户在这个架构上购买时间/资源。这是在云当中，跨越整个Web，确是在那些租用这些服务的公司之外。

　　3.云计算就是将本地服务转移到Web上

　　把本地存储的文件转移到一个安全的可扩展的环境中。从那些受限于磁盘空间的应用转移到没有空间上限的应用中;从使用微软Office到使用基于 Web的Office。在2005年到2008年之间，在线存储变得更加便宜，并且在线的存储比起本地存储或者你自己服务器上的存储更加的安全。这就是云 计算。它包含了网格计算、像Bigtable这样的大型数据库、缓存、总是可以访问、失效恢复、冗余、可扩展以及其它的一些因素。可以把它看作进一步走入 Internet的步骤。它还包含大量的关联，比如静态和动态之间、RDBMS和BigTable以及平式数据观点之间的对比。依赖于IT架构的整体商务 结构都会改变，编程者会驱动整个云计算，并且最终将会产生很多编程者。这就像从大型机到个人计算机的一个转变过程。当前，你就拥有了一个云上的个人空间。

　　这非常的有意思，就像Web 2.0。但是，还是存在着很多的改变。市场都在围绕着整体的技术提升。

　4.网格和云计算两个概念并不排斥

　　我们的客户把它这样来看：

　　云计算就是对资源使用的一种付费(比如，你不必去拥有资源)。

　　网格就是你如何去安排你的工作——而不管你在哪里运行这些工作。

　　你可以在没有网格的情况下使用云，或者相反。同时，你也可以在一个云上使用一个网格。

　　5.通常，我会把云计算的概念分成以下三个阵营：

　　使能者——这些公司可以使能潜在的架构或者基本的模块。这些公司主要关注于数据中心自动化以及服务器虚拟化(VMware/EMC，Citrix，Blade Logic，RedHat，Intel,， Sun，IBM，Enomalism等等)。

　　提供者——(Amazon Web Services，Rackspace，Google， Microsoft)。这些公司拥有预算，并且知道如何来建立全局的计算环境，这通常会花费数百万甚至数十亿美元。云计算提供者通常会提供它们的架构或者 平台。通常，这些服务以付费方式提供，并且基于效用来使用。

　　客户——在整个云计算的另一端，我们看到一些客户公司。它们建立或者提升Web应用在已经存在的云计算环境之上，并且不需要对数据中心或者任何 的物理设施进行资金的投入。通常提供者和客户会是一家公司，比如Amazon(SQS，SDB等等)以及Google(Apps)以及Salesfore (Force)。但是，他们同样也可以重新开始，提供载云计算之上的工具和服务(云管理)。

　　“云客户通常是一个相对广泛的组织，包括那些通过基于Web的服务提供的任意应用，比如Webmail, 博客，网络等等。从客户的观点来看，云计算已经成为一个你创建、主管并且部署一个可扩展Web应用的平台。　　

　　至少现在，我们对于云计算的概念就更加清楚了。

Blogged with the Flock Browser

[转贴文章]ERP实施最恐怖事件：需求变更

辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求， 不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。因为有时候，用户只是简单的一句话，但 是对于系统的调整来说工作量是非常大的。

　　一.需求变更：迁就or拒绝?

　　从ERP项目立项开始，需求就是ERP实施顾问的心头之痛。随着对ERP的深入认识、项目环境的变动，企业内外部多种因素都可能使客户对ERP 的需求不断改变。如果不能有效处理这些需求变更，项目实施进度必将一再调整，上线日期也会随之一再拖延，项目成员的士气也将越来越低落，严重的还会直接导 致ERP项目失败。

　　需求变更，本应是客户的权力，但也是实施顾问的为难之处。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更 宠惯养成堂而皇之的变更。例如，我曾经在某ERP项目中属于“谦虚型”，对于客户提出的变更，无论大小都给予解决，客户对此非常满意。然而，项目进度却拖 得很长，项目一再延期。相比之下，在另一个项目上我显得稍有些“盛气凌人”，对于客户提出的需求变更，大多都不予理睬，客户对此不是很满意。不过，该项目 的进度控制得较好，基本能按期完成项目。

　　按后一种“盛气凌人”的做法，对客户的要求一概不理，自顾自地按照最初的需求和计划实施，很可能会由于没有用户的参与，使得ERP系统与用户的 需求相差甚远，导致验收通不过，收不回尾款而使公司利益受损。对于客户来说，达不到需求的满足也浪费了投资。事实上，客户不满意，则项目就不算成功，实施 顾问辛勤劳动最后就只能落得个“没有功劳，只有苦劳”的份。

　　但按前一种“谦虚型”做法，完全顺着客户的意见走，客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加，甚至可能会出 现大量的无效劳动。而且，频繁变动的需求也会导致实施质量下降，留下许多隐患。因此，一味的迁就用户将会使进度一拖再拖，实施方案一改再改，变更越来越 多，士气越来越疲，公司越来越不满意，用户越来越急。到最后，实施顾问会发现这个项目已经成为了一个“不可能完成的任务”。

　　二.需求变更为什么总是做不完?

　　在ERP实施过程中，实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是ERP项目与 生俱来的特性，也是一个无法避免的事实。需求变更的表现形式是多方面的，如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致 ERP实施过程中成本增加、进度拖延等风险，而且越往后的变更产生的风险将越大。

　　以笔者参与的多个ERP实施项目的实际经历来看：需求变更泛滥是非常可怕的事，尤其是到了项目实施后期，客户不断对移交的ERP系统提出修改意 见，甚至有时刚刚重新完成的更改，客户又要求改回去或改成另一种模式。需求变更越来越多，实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行ERP项 目的共同感觉。

　　实施顾问作为项目的承担者，在规定时间内利用有限资源保质保量的完成项目，让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗?我们分析一下出现需求变更的根源。

　　(1)合同签订马虎，没有真正明白客户需求

　　签订合同时缺乏对客户需求认真对待，导致需求描述不清，为后期的实施工作带来困惑。ERP销售顾问为使客户能够快速的签订合同，往往草率决定和 片面同意客户提出的需求。当客户提出新的需求时，往往是销售顾问一看“应该”只是一个小小的修改，没有太大的影响，所以直接答应能变更。

　　该问题的关键是合同签署的太烂，没有把需求明确再签合同，而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚，后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围，可以为以后各项实施工作的开展奠定深厚的基础。

　　(2)调研时没有深入理解客户需求

　　在ERP上线前的需求调研分析阶段，项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进 行。更严重的是，实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案，没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导 一拍脑袋提出新的需求时，实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分，双方对需求的理解就会产生差异，就会 导致移交ERP系统时才使问题暴露出来，客户只能频繁的提出需求变更。

　(3)没有明确的需求变更管理流程

　　没有明确的需求变更管理流程，就会使需求变更变得泛滥。并不是所有的变更都要修改，也不是所有变更都要立刻修改，需求变更管理的目的是为了决定 什么类型的变更需要修改和什么时候修改。比如ERP界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改没 有严格把关流程，有些小需求看起来工作量不大，但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。

　　(4)没有让客户知道需求变更的代价

　　对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客 户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗?”。

　　三.如何有效控制需求变更?

　　需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。例如授权、审核、评 估和确认，在实施过程还要进行跟踪和验证。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”

　　用户需求的变更总是不可避免的，所以我们要以积极的心态去接受和控制用户的需求，而不仅仅是埋怨。对待客户频繁的需求变更，应采取有效办法应对，避免事态蔓延，不让客户养成随意变更的毛病。

　　(1)合同约束

　　需求变更给ERP实施带来的影响是有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝或部分接受，还可以规定发生需求变更时必须执行变更管理流程。

　　虽然ERP项目合同很难在签订之初就能够精确定义每项需求，单靠合同是帮不上忙的，但也不能忽视合同的约束力。有一个笑话，就是许多销售顾问都开玩笑说他们都是清政府。为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。

　　(2)建立需求变更审批流程

　　要明确需求变更审批环节、审批人员、审批事项、审批流程等。目的有两个：一是将客户下达变更的流程尽可能地规范化，减少张嘴就来的非必要、非紧 急、非合理、非高层领导意图的“无效变更”。二是留下书面依据，为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”，一律是无效变 更不予受理。

　　有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响，以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有 书面材料，当用户发现由于业务变化而引起的需求变更，需要提出书面申请。这样对所有的变更，双方的项目负责人都能做到心里有数。而且用户在递交书面变更申 请时比较慎重，一般都在内部经过讨论后进行，这样减少了因用户内部看法不同导致的反复变更。

　　(3)对于零星变更，集中研究、批量处理

　　每周或每两周甚至每月召开一次需求变更专题会议，集中研究处理这些零碎变更事项，主动控制好工作节奏，尽量避免由于处理零碎变更而影响项目运行 的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划，注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划，确定变 更时限，控制变更规模，过时变更不候，离谱的变更不做，保大局弃小变。

　　(4)评估各种需求变更的影响

　　客户的需求是永远不会满足的，可能一天一个样,为了达到控制频繁的需求变更。需要将需求变更后产生的成本进行评估与量化，形成分析报告提交双方 领导。否则，一味的妥协只会让项目进一步恶化，实施顾问需要掌控客户及公司的进度成本，把客户的每一次需求变更进行成本分析。确认哪些需要收费变更，哪些 可以免费配合客户。这样既可以维护客户关系，又不致造成公司无谓的损失。

(5)确认客户是否接受变更的代价

　　要让客户认识到变更都是有代价的，要和客户一起判断需求变更是否依然进行。例如，变更是没有问题的，但是要明确客户能否接受由此引起的如进度延 迟、费用增加、效率下降等问题。一般来说，如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果，通过与客户的协商，项目组可能会 得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。

　　如果客户认为该变更虽然有必要但是可以暂缓，双方签署备忘录后留待以后解决。如果客户认为该变更可有可无，多数情况下会取消变更。这样即可防止 频繁变更，也让客户认识到不是所有的需求都需要变更，更不是所有的需求变更都需要立刻修改。客户一般对ERP不甚了解，他们认为很简单的事情，但可能解决 起来会很复杂。以笔者的经验来看，一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现，也可以安排在现有功能的 完善之后。

　　(6)每月变更记录上报双方领导

　　最后，实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理 的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。

　　最后，要特别提醒，要在ERP项目开始就对项目组和客户进行宣传和培训，让所有成员都理解变更控制的重要意义。

Blogged with the Flock Browser

[转贴文章]从玩具到游戏 看另类项目激励机制

通过发奖金的形式来激励团队成员，本身就是一把双刃剑，弄得不好，可能就会破坏团结，导致彼此之间的矛盾与冲突，这对于一个团队而言是绝对致命的。然而，如果一个团队缺乏合理的激励方式，又无法调动成员的积极性。如何取舍，真是伤透脑筋。

......昨日阅读Larry L. Constantine的《人件集——人性化的软件开发》，才发现其实Constantine早已给出了答案，就在书中的第59章《受奖励的程序员》中。 原来，我们为什么要受限于发奖金这样一种形式呢？套用一句俗语说，“提到钱，就难免伤感情了。”要激励团队成员以及开发团队，我们还能够寻求到很好的方 式。

概括起来，Constantine提出的激励机制包括如下内容：

1、“技术玩具”。开发人员大多数都是技术型人才，一个通病就是对于技术的执著追求有时候甚至高于对金钱的追求（前题是他已经具有优裕的生活基础）。因 此，一套最新的正版软件工具，或者一件当前最酷的数字产品，都会让他们欣喜不已。这种“投其所好”的馈赠方式，既没有奖励金钱那么赤裸，又能够让开发人员 从内心深处激发对公司的认同与感激，真可谓两全其美。

2、小礼品。书中写道：“绝不要低估T恤衫的力量。各式各样的‘刺激’手段——团队夹克、特殊的领带、特别的杯子或者鼠标垫——都是可以使用的方法，这 些，能够告诉那些取胜的团队以及团队成员：他们与别人不太一样。最好的团队还可以获得自己设计团队徽章样式的机会，并有公司负责找人生产。”这种方式或许 是高层领导最愿意看到的，投入不多，却极尽蛊惑人心之能事，尤其是设计团队徽章的做法，既能够激发个人的集体荣誉感，又能够激励整个团队的战斗力。

3、自由控制的时间。这里提出的自由时间，并不是奖励成员出去旅游或者度假，而是对于那些按时交付了高质量软件的开发人员，奖励他们能够在公司的上班时间 内，自由支配自己的工作，做自己感兴趣的事情（当然是与技术相关的）。例如，你可以自由自在地在没有最后期限的压力之下研究网格运算，或者神经网络，人工 智能，哪怕你所在的公司实际上只是从事SAP二次开发。

Rob Thomsett说，按照他的经验，如果你把时间和钱放在一起让程序员挑选，大多数都更喜欢前者。而这类由公司赞助的研究活动，反过来对公司也是有益的， 不但是获得了一位拥有新技能和新点子的快乐的开发者，而且，没准儿还能得到一个新的软件或者其他什么有用的技术。这种奖励方法对整个团队可能更有意义。如 果一个项目团队显示出他们的高超的开发执行能力，当他们超越了公司建立的最好实践之上时，那么就应该对这个团队进行奖励，让他们可以无拘无束地选择研究和 开发项目。

如果你的公司是一家研究型公司，或者从事产品开发，这样的奖励方式在激励成员以及团队工作热情的同时，或许还能得到意外的收获。最关键的是，这种做法无形中营造了公司的研究氛围，创造了一种良好的价值取向。

4、教育与培训机会。特别对于具有进取心的开发人员而言，获得教育或培训的机会，绝对比获得奖金更加诱人。即使管理者担心教育与培训投入的成本太高，甚至 会造成人才流失的可能，那么，给团队人员一次参加技术大会的机会好了。这些大会往往都是免费的，开发人员需要获得的仅仅是你的一个许可而已。然而，已经足 见你的栽培之心了。Constantine还说道：“报销书籍和杂志费用也是一种低费用的激励方式”。管理者们，你们看到了吗？

5、选择团队成员的权利。权利也是一种奖励。例如让他主持一次会议，或者提供监督别人的机会，都是一种廉价的权利，但有可能得到的回报却很丰厚。最好的权 利就是允许团队成员能够挑选自己认可的合作者。书中提到：“一旦一个小组已经学会了如何协同工作，为什么要把他们分开呢？对于那些能够高效开发的团队，奖 励方法之一就是让他们在下一个项目中继续共同工作。对这个方法进行一个推广，那么，我们可以让他们自行挑选工作伙伴，这种行为可以有效地激励员工，使他们 能够达到最好的工作效果。同理，让那些在上一批项目中干得最好的团队，在下一批项目中自由选择员工，对他们来说，也是一种奖励。”还有什么比这个更加廉价 的奖励。

除了以上提到的五点之外，Cockburn在《敏捷软件开发》一书中，还提到了Darin Cummins发明的一种开发游戏的奖励方式，奖励一些类似于代金券之类的伪币，然后在项目结束后，利用这些伪币来竞拍一些真正适用的物品。关键不是这个 结果，而是开发中的过程，对于成员的奖励就像玩游戏一般轻松自在，不知不觉就剥去了成员的功利之心，有效地消除成员之间的恶性竞争。

Darin写道：“开发人员会因为他们的代码被评审、评审其他人的代码、按照进度完成任务、重用代码以及创建单元测试等得到奖励”。要消除成员之间的恶性 竞争，这种方法一定要遵循两点。第一是将过程尽可能最小化，这样的度量会更加准确与透明，不会出现太大的分歧。第二则是给参与者反败为胜的机会。可以在开 发过程的结尾，设计一些额外的活动来让开发人员赚取更多的奖励。这样一来，即使开发人员在前面输得太多，他仍然有机会在后程发力，反败为胜。

适当的奖励可以让我们踢开刀刃，自在轻舞，但必须还要谨记如下两个原则：

• 在奖励优秀的开发人员的同时，不要忘记对优秀团队的奖励；
• 奖励方式应因人而异，必须最大程度地投合员工的喜好。

因此，在对你的团队以及员工进行奖励之前，最好先询问他们究竟喜欢什么，也许你能够以最小的投入换来最大的回报。坦白说，有时候上级也需要好好考虑如何对下级“拍马屁”呢。

Blogged with the Flock Browser

［转贴文章］使用memcached进行内存缓存: 一个藏袍

使用memcached进行内存缓存: 一个藏袍

使用memcached进行内存缓存

旧文重发
2005.8.9

通常的网页缓存方式有动态缓存和静态缓存等几种，在ASP.NET中已经可以实现对页面局部进行缓存，而使用memcached的缓存比 ASP.NET的局部缓存更加灵活，可以缓存任意的对象，不管是否在页面上输出。而memcached最大的优点是可以分布式的部署，这对于大规模应用来 说也是必不可少的要求。
LiveJournal.com使用了memcached在前端进行缓存，取得了良好的效果，而像wikipedia,sourceforge等也采用了或即将采用memcached作为缓存工具。memcached可以大规模网站应用发挥巨大的作用。

Memcached是什么?
Memcached是高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。
Memcached由Danga Interactive开发，用于提升LiveJournal.com访问速度的。LJ每秒动态页面访问量几千次，用户700万。Memcached将数据库负载大幅度降低，更好的分配资源，更快速访问。

如何使用memcached-Server端?
在服务端运行：
# ./memcached -d -m 2048 -l 10.0.0.40 -p 11211
这将会启动一个占用2G内存的进程，并打开11211端口用于接收请求。由于32位系统只能处理4G内存的寻址，所以在大于4G内存使用PAE的32位服务器上可以运行2-3个进程，并在不同端口进行监听。

如何使用memcached-Client端?
在应用端包含一个用于描述Client的Class后，就可以直接使用，非常简单。
PHP Example:
$options["servers"] = array("192.168.1.41:11211", "192.168.1.42:11212");
$options["debug"] = false;
$memc = new MemCachedClient($options);
$myarr = array("one","two", 3);
$memc->set("key_one", $myarr);
$val = $memc->get("key_one");
print $val[0]."\n"; // prints 'one‘
print $val[1]."\n"; // prints 'two‘
print $val[2]."\n"; // prints 3

为什么不使用数据库做这些？

暂且不考虑使用什么样的数据库(MS-SQL, Oracle, Postgres, MysQL-InnoDB, etc..), 实现事务(ACID，Atomicity, Consistency, Isolation, and Durability )需要大量开销，特别当使用到硬盘的时候，这就意味着查询可能会阻塞。当使用不包含事务的数据库（例如Mysql-MyISAM），上面的开销不存在，但 读线程又可能会被写线程阻塞。
Memcached从不阻塞，速度非常快。

为什么不使用共享内存?
最初的缓存做法是在线程内对对象进行缓存，但这样进程间就无法共享缓存，命中率非常低，导致缓存效率极低。后来出现了共享内存的缓存，多个进程或者线程共享同一块缓存，但毕竟还是只能局限在一台机器上，多台机器做相同的缓存同样是一种资源的浪费，而且命中率也比较低。
Memcached Server和Clients共同工作，实现跨服务器分布式的全局的缓存。并且可以与Web Server共同工作，Web Server对CPU要求高，对内存要求低，Memcached Server对CPU要求低，对内存要求高，所以可以搭配使用。

Mysql 4.x的缓存怎么样?
Mysql查询缓存不是很理想，因为以下几点：
当指定的表发生更新后，查询缓存会被清空。在一个大负载的系统上这样的事情发生的非常频繁，导致查询缓存效率非常低，有的情况下甚至还不如不开，因为它对cache的管理还是会有开销。
在32位机器上，Mysql对内存的操作还是被限制在4G以内，但memcached可以分布开，内存规模理论上不受限制。
Mysql上的是查询缓存，而不是对象缓存，如果在查询后还需要大量其它操作，查询缓存就帮不上忙了。
如果要缓存的数据不大，并且查询的不是非常频繁，这样的情况下可以用Mysql 查询缓存，不然的话memcached更好。

数据库同步怎么样？
这里的数据库同步是指的类似Mysql Master-Slave模式的靠日志同步实现数据库同步的机制。
你可以分布读操作，但无法分布写操作，但写操作的同步需要消耗大量的资源，而且这个开销是随着slave服务器的增长而不断增长的。
下一步是要对数据库进行水平切分，从而让不同的数据分布到不同的数据库服务器组上，从而实现分布的读写，这需要在应用中实现根据不同的数据连接不同的数据库。
当这一模式工作后（我们也推荐这样做），更多的数据库导致更多的让人头疼的硬件错误。
Memcached可以有效的降低对数据库的访问，让数据库用主要的精力来做不频繁的写操作，而这是数据库自己控制的，很少会自己阻塞 自己。

Memcached快吗？

非常快，它使用libevent，可以应付任意数量打开的连接（使用epoll，而非poll），使用非阻塞网络IO，分布式散列对象到不同的服务器，查询复杂度是O(1)。

参考资料：
Distributed Caching with Memcached | Linux Journal
http://www.danga.com/
http://www.linuxjournal.com/article/7451

Blogged with Flock