CSBlogV2.11的更新历史记录：http://max.cszi.com/Blog/565-1.aspx

1. 如果出现要求写权限的错误，请打开Everyone的读写权限。并且数据库的只读属性要去掉。

2009新年贺岁版－ 牛气冲天下载：

1. http://down.chinaz.com/soft/24379.htm

2. http://files.cnblogs.com/atwind/CSBlogV211-Preview1.rar



Q: 为什么新发表的Blog会出现重写错误?
A: 原因是读取不到评论的集合及分页信息,解决办法一是让所有角色都可以读取评论,二是在Blog.xslt(这个对应你的主题的Blog目录下)修改136行附近的原内容为:

  <xsl:if test="$Collection">
    <div  class="comment-page"  xml:space="preserve">
    <xsl:call-template name="UI.RePaging">
      <xsl:with-param name="Paging" select="$Paging" />
      <xsl:with-param name="BaseUrl" select="cs:makePage('/Blog/Blog.aspx','BlogDetail',$Paging,$Blog/@Id)" />
                  </xsl:call-template>
                </div>
  </xsl:if>

第二种办法是解决的根本.

----------------------------------------------------------
热心网友建议及回复:

1.大图片应该能自适应最大页面框架，超出某个比例时，将显示最大宽幅的自适应显示器和浏览器的页面（有滚动条也行），不过这一点不太重要。
A: 这个可以在后面设定一个比较小的缩略图,而不是直接设为最大的.(因为大图对客户端的下载也是个问题.) 还有个办法就是CSS来控制,溢出时自动隐藏(Baidu 是这样的)

2.图片（附件）上传后，在编辑状态中后或者重新上传，对于指定的上传文件夹中无效的旧图片和附件，系统均应自动给与删除。
A: 这个将在下一版本上实现.

3.后台可以查看图片附件以及手动清理非有效链接附件（图片）。
A: 这个将在下一版本上实现.

4.标签总管理，应该可以删除或者修改。
A: 这个暂时记下

5.系统自动识别图片后，在相册中集中显示；或者单独开设相册（画册）栏目，以列表幻灯等多种模式显示。
A: 这个将在下一版本上实现.

6.图片上传有时有故障，上传不能成功，需要查找原因修正。
A: 下一版本改进

7.留言板不可用,不过我考虑外挂一个，因为也有很不错的小型留言板。
A: 下一版本的插件形式发布

8.用户中心不可用，这需要及早修复，因为会影响用户体验。
A: 因为现在基本上是本人,所以大多是直接在后台更改,下一版本中改进

9.用户Norton(Symantec）防火墙开启时，诸多功能都出现异常，比如回复，显示为未知错误，但在无验证码情况下，在显示错误的同时，能发布。发文章和图片上传则不行。
A:这个没有碰到过,回头我查一下.

10.后台给管理员在后台查看文章标题和所有评论的功能，可以随时总览文章以及评论，方便删除。目前前后台管理分离，分别授权。习惯上后台管理权限应该包括前台管理。但方便起见，增加对文章列表、评论列表、标签列表的管理即可。
A: 暂时记下

11.ReWrite重写，可否写成html的后缀？搜索引擎很喜欢。
A:Html后缀是直接要修改IIS的解析指向的,这个可以在IIS上自已改.已经实现

12.从百度搜索官方站点看，搜索到的内容部分，需要进行改进。目前在meta使用了优秀的调用前部分文章文字功能，但没有发挥作用。
A:我的SEO确实是凭感觉,回头好好看一下!

13.ACC数据库总保持在出现ldb打开的状态，我不懂，不知道是否是同程序代码有关？
A: 一直保持在打开状态是能为了更快速的响应数据读取与更新,可以在后台暂时关闭.

2、一定要确定自己的发展方向，并为此目的制定可行的计划。
    不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过 你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先 在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。

3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！
     在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队 中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤 陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”（非 技术型）带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整（软件开发技术变化实在太快）。
     请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用 将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。

5、书籍是人类进步的阶梯，对软件开发人员尤其如此。
     书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些 家伙出的书，100%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技 能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。

6、不要仅局限于对某项 技术的表面使用上，哪怕你只是偶尔用一、二次。
     “对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看 Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、

     Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。 试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！

7、在一种语言上编程，但别为其束缚了思想。
     “代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由， 所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。

     我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具（目前主要有VC++、Delphi） 进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀 的开源框架？在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式？为什么一切都必须 以个人、团队在当然开发语言上的传统或者经验来解决问题？？？“他山之石、可以攻玉”。

8、养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。
     众所周知，对软件开发人员而言，有、无经验的一个显著区别是：无经验 者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题（其实这个结论不应该被局限在软件开发领域、可以延伸到很多方 面）。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是，最好还是自己实现，这样没 有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。

9、理论与实践并重，内外双修。
    工程师的内涵是：以工 程师的眼光观察、分析事物和世界。一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发的思想精髓的人（个人观点、欢迎探讨）。掌握软件开发 语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个角度来看，这只是外在的东西，并非重要的、本质的工 作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题，才是真正的软 件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些思想与方式，最终形成自己的理论体系和实用方法论。

10、心态有多开放，视野就有多开阔。
      不要抱着自己的技术和成果，等到它们都已经过时变成垃圾了，才拿出来丢人现眼。请及时发布自己的研究成果：开发的 产品、有创意的设计或代码，公布出来让大家交流或者使用，你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具，5、6 年之后的今天，还是那个样子，今天流行的好多Windows系统工具都比自己的晚，但进化得很好，且有那么多用户在使用。并且，不要保守自己的技术和思 想，尽可能地与人交流与分享，或者传授给开发团队的成员。“与人交换苹果之后，每个人还是只有一个苹果；但交换思想之后，每个人都拥有两种思想”，道理大 家都懂，但有多少人真正能做到呢？

11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。
      网络早已不再只是“虚拟世界”，网上有很多的开源项目、合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工 作是做ERP，就不去学习和了解嵌入式、实时、通信、网络等方面的技术，反过来也是一样。如果当别人拿着合同找你合作，你却这也不会，那也不熟时，你将后 悔莫及。

12、书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。
      诺贝尔经济学奖得主西蒙教授的研究结果表明：“对于一个有一定基础的人来说，他只要真正肯下功夫，在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果，故命名为西蒙学习法。
       可见，掌握一门陌生的学问远远没有想象的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识，有空花时间看看，韬光养晦、未雨绸缪。

13、本文的总结与反思：
 A：不要去做技术上的高手，除非你的目标如此。虽然本文是关于提高软件开发知识的建议，做技术的高手是我一向都不赞同的。你可以提高自己的专业知识，但能胜任工作即止。
 B：提高软件知识和技术只是问题的表面，本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理，可以很容易地延伸、应用到生活的其它方面。
 C：在能胜任工作的基础上，立即去涉猎其它领域的专业知识，丰富自己的知识体系、提高自己的综合素质，尤其是那些目标不在技术方面的朋友。

原文地址：http://www.cnbeta.com/articles/98455.htm
砖家给出了4个理由来反驳2012是世界未日，可是我发现它写的东东，它自已都不信。都没有明确和肯定的结论。还有第一个的比较，太扯淡了。地磁对人的影响，是可以不计，它真正影响的是太阳的高能粒子，将这些高能粒子给转到南北两极，而不是直接投射到地个上，如果要造一个这样效果的磁铁，你要造多大的磁铁才能做 到这个效果？

并且2012年太阳太黑子确实会大规模的爆发，这有多少影响知道吗？ 它们会影向暴露在阳光下人们的皮肤，它们会影响作物的生长，它们会使卫星能通信受到非常严重的影响。这些还不够吗？ 假设突然出现不可预测的大爆发，大阳风大量的的能量来到地球，加速两极冰盖的融化，这些还不够吓人的吗？

人类在其历史的短短的进程中，像病毒一样，把地球给搞的千疮百孔的。地球呢？现在已经开始显示出她自我调节能力了，近年来的未明的病毒，如果调节不过来，那真的是未日不远！ 我相信地球随咳嗽一下，抖几下身子，那结果可想而知了。人类能通过这弹那弹来毁灭的只能是人类，而不是地球。

如果，2012真的是未日，那也是人类的未日，不是地球的未日。

如果，2012真的是未日，你会去做什么？在这两年内。

【附：为什么现在GOV一直在不停洗老百姓的米？我可以认为是在制做诺亚方舟不？】

胡言乱语，一家之言，如明雷同，那也活该！

经过对比，我发现这是非常合适的一个条件，谷歌只显示我的书的目录和摘要，就支付给我60美元。回首祖国，无数的网站都能下载我的书的全文，从1999年2009年，我从来没有收到过一分钱。现在谷歌仅仅刊登了我的书的目录，就支付给我60美金，我觉得非常的满足。这十年来，我曾一度接近可以通过互联网赚点稿费，在2000年的时候，某中文网曾经和我签约第一本书的电子版权，在点击和下载量终于可以接近10000人民币的时候，突然间所有数据都变成0了，后来就再也没有人提起过这事。在中国，唯独起点中文网支付给我网络连载的费用，但那是针对尚未出版的新小说。

1.  System.Configuration.Configuration config =   
2.      ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);   
3.   
4.  AppSettingsSection appSetcion = config.GetSection("appSettings") as AppSettingsSection;   
5.  appSetcion.Settings["AutoRun"].Value = "this is  a test";   
6.   
7. // ConfigurationManager.AppSettings["Save"] = isCheck.ToString();   
8.  txtMessage.Text += ConfigurationManager.AppSettings["AutoRun"];   
9.  config.Save();   

注意：要使用Section操作才行。直接用Appsettting["somekey"]是不行的

Oracle里的包内容：

在Toad里编译能通过，PLSQL Developer里则有问题。不知啥原因，知道的高人回答一下。呵~~~

后面的都准备写在评论里了。这样方便。嗯！

服务器环境：

linux as 4 + oracle 10g 内存1G，Xeon3.0G 处于Windows平台下的虚拟机。

差不多每秒种3000多条数据，第二次执行的时候是318秒多一点。

select count(0) from test_temp 时约0.2秒大右，加上ID> 300000的条件，为0.02秒左右。

ID是用序列和触发器来生成的。

我们不仅仅要学会做除法，还要学会解读政府的官话。

虽然官话里有百分之九十九是废话，但还有百分之一的屁话，这百分之一决定了政府经过考虑以后的方向，里面往往蕴含了很多的讯息。无论从商从政都要有良好的解读能力。

从顺序上来说，政府是不甘心的，因为政府强调了要坚决依法整治非法运营，表明了他们咽不下这口气，但是这次的确是栽了，后面那一句坚决禁止不正当取证行为是表示，老子暂时认栽。

但是，政府会两次栽到同一条河里吗？很遗憾，答案是会的。因为正常人都不大会。但是政府经常同样一条河里要掉好多次，只是在不同的地方以不同的姿势掉进去。当然，永远淹不死那就是他的本事了。

我认为，这次的事件中，闵行是占了便宜的，因为舆论的导向最后都指向了浦东新区。说不定闵行出事那会儿，浦东正笑闵行呢，哪知古有孙中山断发明志，今有孙 中界断指明智。上海倒钩茂盛的地方时闵行和南汇，这次南汇并入了浦东，所以浦东也算是继承发扬了原南汇的光荣传统。文章写到这里，提醒大家，无论是从倒钩 数量和次数来说，闵行很可能是老大，勿忘闵行。

但是这样影响恶劣的事情，为什么市政府的态度从一开始就比较纵容呢，为什么要让这样的事情一再破坏政府的公信力呢？原因之一是一看自己，靠，原来本来就没 什么公信力了，也就算了。原因之二，那就是钱。据报道，在闵行倒钩见报以后，闵行区马上刊登了一个来自运管局的工作报告，报告称，在过去两年里，通过这样 的方法，罚款了5000多万元，超额完成了上级的指标。

按照我们的理解，这是很白痴的一件事情，千夫所指的时候还要留人把柄，顶风作案，好比你已经杀了一个人，突然你跳出来说，这两年我其实杀了二十个。但是官 员是很蠢的，他们之所以这么写，是在提醒他们的上级，我有功啊。从黑社会的角度来理解就比较容易，就是大哥说，教训一下这帮人，小弟一出马，弄死一帮，出 事了。小弟立马说，爷，你要保我啊，是你让我干的啊，你看，我都超额完成了，你让我教训一下，我不光教训了，还弄死了二十个。

老大一挠头，说，你这个白痴，让你教训一下就好，你弄死人家干嘛呢？

小弟说，爷，这不弄死，怎么扬你的威风呢？

老大说，事情弄这么大，我暂时也保不住你，你出去避避风头吧。

小弟说，爷，你一定得帮我啊，我还帮你多收了5000多万呢。

老大，算了算了别说了……

这样大家就好理解各种关系了，是的，那5000多万赃款是让闵行运管洋洋得意政绩，在这件事情上，我认为不是简单的老大出面说一句我的小弟这次没做好这么 简单的事情，因为这个不是犯错，这是犯罪。还有专家为倒钩辩护说，美国警察也警察倒钩，他们假装吸毒的去倒钩毒贩子。我们且不说这个比喻有多么愚蠢，但我 们做的事情也不是这样的啊，我们干的就是假装吸毒的去倒钩普通人，一看不是就往他手里塞一包毒品，然后立马把人家当贩毒的抓起来。

倒钩事件里，政府部门涉嫌到非常多的犯罪行为，包括抢劫罪，诈骗罪，诬陷罪，非法拘禁罪，故意伤害罪和组织黑社会罪，而不是执法不当的行为，我认为上海市 政府的这个处理态度是在转变事情的性质，引导舆论和公众这只是一起执法不当而已。另外，我提醒一下广大的真正的黑车司机，你们最近要小心了，大家都是在这 个生存起来很艰难的城市里混口饭吃，但是按照政府的一贯手腕，倒钩一案过去以后，将进行集中的黑车整治活动，将有更加严密的取证手段和处罚，再加上出租车 刚刚涨价，你们可能要不幸，所以要做好准备。

这件事情的合理处理方式，我认为应该是这样的才合理：

1，  政府改变出租行业的管理方法，降低入行门槛，减免对出租车司机的压迫。

2，  让广大黑车司机成为正规出租车司机。

3，  对运管局进行全面的停业整顿。

4，  追查5000万抢劫款的用处（虽然这钱对于政府来讲很不起眼）将5000万的抢劫款全部退还到个人，哪怕里面有4000万是真正的黑车处罚，一个健全的美好的城市其实是不存在非法运营这四个字的。

5，  对于第一次非法运营的人不做处罚，只做记录，到第二次才实行处罚，这样就可以大大降低甄别失误，如果是好人，就等于告诉他，以后别让人搭车了。

6，  对闵行区政府主要领导进行处罚和撤职。对相关人员论罪处罚。

7，  副市长（包括）以上级别相关领导引咎辞职。

以上七条其实是在任何一个法制国家里最常见的处理方法，你可以经常看见其他国家地区的领导因为屁大的事情就引咎辞职，但我国的领导哪怕出了天大的事情都还 巍然不动，最多就道歉一下完事，原因其实很简单，你忍心法办经常和你一张桌子上吃饭的朋友吗？你忍心法办和你在一张床上嫖娼的兄弟吗？

所以，解决问题的根本中的根本就是，严禁公务员在一张桌子上吃饭。

此事如果没有彻底解决的方法，我建议全上海的驾驶员在世博会期间在车上贴上中文英文日文法文大标语告示国外友人：莫伸手，伸手必被捉。

这是个什么样的世界啊，写下这句话的原上海市市长陈毅肯定也想不明白一个世纪后的上海，明明是你伸的手，为什么被捉的却是我呢？

最后，随文免费附送陈毅的作品

《七古·手莫伸》： 陈毅
手莫伸，伸手必被捉。党和人民在监督，万目睽睽难逃脱。汝言惧捉手不伸，他道不伸能自觉，其实想伸不敢伸，人民咫尺手自缩。岂不爱权位，权位高高耸山岳。 岂不爱粉黛，爱河饮尽犹饥渴。岂不爱推戴，颂歌盈耳神仙乐。第一想到不忘本，来自人民莫作恶。第二想到党培养，无党岂能有所作？第三想到衣食住，若无人民 岂能活？第四想到虽有功，岂无过失应惭怍。吁嗟乎，九牛一毫莫自夸，骄傲自满必翻车。历览古今多少事，成由谦逊败由奢。


http://blog.sina.com.cn/s/blog_4701280b0100fk2m.html

decimal(numeric )             同义，用于精确存储数值

float 和 real                      不能精确存储数值

decimal数据类型最多可存储 38 个数字，所有数字都能够放到小数点的右边。decimal数据类型存储了一个准确（精确）的数字表达法；不存储值的近似值。

定义decimal的列、变量和参数的两种特性如下：

p   小数点左边和右边数字之和，不包括小数点。如 123.45,则 p=5，s=2。
指定精度或对象能够控制的数字个数。

s
指定可放到小数点右边的小数位数或数字个数。

p 和 s 必须遵守以下规则：0 <=s<=p<= 38。

numeric和decimal数据类型的默认最大精度值是 38。在 Transact-SQL 中，numeric与decimal数据类型在功能上等效。

当数据值一定要按照指定精确存储时，可以用带有小数的decimal数据类型来存储数字。

float 和 real 数据
float和real数据类型被称为近似的数据类型。在近似数字数据类型方面，float和real数据的使用遵循 IEEE 754 标准。

近似数字数据类型并不存储为多数数字指定的精确值，它们只储存这些值的最近似值。在很多应用程序中，指定值与存储值之间的微小差异并不明显。但有时这些差异也值得引起注意。由于float和real数据类型的这种近似性，当要求精确的数字状态时，比如在财务应用程序中，在那些需要舍入的操作中，或在等值核对的操作中，就不使用这些数据类型。这时就要用integer、decimal、money或smallmone数据类型。

在 WHERE 子句搜索条件中（特别是 = 和 <> 运算符），应避免使用float或real列。最好限制使用float和real列做> 或 < 的比较。

IEEE 754 规格提供了四种舍入模式：舍入到最接近的值、上舍入、下舍入和舍入到零。Microsoft® SQL Server™ 使用上舍入。所有的数值必须精确到确定的精度，但会产生细小的浮点值变化。因为浮点数字的二进制表示法可以采用很多合法舍入规则中的任意一条，因此我们不可能可靠地量化一个浮点值。

转换 decimal 和 numeric 数据
对于decimal和numeric数据类型，Microsoft® SQL Server™ 将精度和小数位数的每个特定组合看作是不同的数据类型。例如，decimal(5,5) 和decimal(5,0) 被当作不同的数据类型。

在 Transact-SQL 语句中，带有小数点的常量自动转换为numeric数据值，且必然使用最小的精度和小数位数。例如，常量 12.345 被转换为numeric值，其精度为 5，小数位为 3。

从decimal或numeric向float或real转换会导致精度损失。从int、smallint、tinyint、float、real、money或smallmoney向decimal或numeric转换会导致溢出。

默认情况下，在将数字转换为较低精度和小数位数的decimal或numeric值时，SQL Server 使用舍入法。然而，如果 SET ARITHABORT 选项为 ON，当发生溢出时，SQL Server 会出现错误。若仅损失精度和小数位数，则不会产生错误。

上周周4在京东上订的。

结果硬是到周二才给送到。比以前慢了太多。这个折腾就不说了。

工厂模式下的信息：

用System.Net.Mail给Gmail发信时：System.Net.Mail.SmtpException: SMTP 服务器要求安全连接或客户端未通过身份验证。 服务器响应为: 5.5.1 Authentication Required. Learn more at       

网上查的时候也没有找到。后来在邮件账号的POP设置里对从现在起所收到的邮件启用 POP 启用一下就OK了。

尽管这些扫描后的数字版本从未向公众发行，无损他们分毫的经济利益；尽管google愿意为“擅自扫描”而向他们支付不少于60美元的支票；尽管google愿意将这些数字图书今后可能产生的发行收益的63％都交给作家（众所周知，在中国，传统的图书出版行业，作家只能拿到4-10％的版税，而绝大多数情况下他们连这点版税都拿不到，只能拿一笔固定稿酬），他们还是像被烟头烫了屁股那样跳了起来。

确实，有人拿烟头烫了他们的屁股，只不过不是google。每一场傻子之间的战争背后，都蹲着聪明人。

说作家傻，因为他们被当枪头使了还自以为义正词严，他们被文字游戏愚弄了还义愤填膺；说google傻，因为他们花钱都没花对地方。假设，他们把这60美元和63％的发行收入打包给文著协，全权委托后者处理，那不管作家们实际拿到手多少，google数字图书馆项目在中国的推进都会比其他任何国家都顺利。

有傻子就有聪明人。美国有聪明人，所以美国出版商协会和美国作家协会才会迅速地选择与google和解。在这个豢养了海量律师的国度，如果所谓的“擅自扫描”真的与现行著作权法和公序良俗相抵触，出版商协会和作家协会是不会放弃向google这个大号金主敲竹杠的机会的。中国也有聪明人，拿烟头烫作家屁股的那些就是。

最后多说一句：傻子是很可怜的，但某些可怜到极致的人，也脱不了可恨之处。比如王小峰，又一次在不明所以的时候开炮，还洋洋洒洒写了一大篇。读完他的那篇blog我才知道，丫根本连google图书馆是干嘛的都不知道，而所谓“股沟”对他著作的侵犯也都来自于自虐狂似的臆想。不独他，某律师，某专家，某记者，某作家……一堆人这两天都忙活来忙活去的发言，在基本事实都不清楚的前提下就长篇大论。之所以点王小峰的名，是因为他今年七月份刚写过两篇博客来阐述他关于著作权保护方面的理论，里头的观点跟他现在的观点就不是一回事儿。反正理都在他这边。知道一，能说出十，总能有理，总能概括推演类比……这种人我们在生活中倒也不少见——比如在bbs上的愤青版面，或者京B牌照小汽车的驾驶座上。

查看：原文地址

欢迎各位访客积极来稿或发言，说出您的意见。如为转载，烦请注明原文地址，不胜感激。
评论仅代表评论者个人意见，不代表cnBeta观点。

在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（10¹⁵或2⁵⁰）来计算——可伸缩性是生死交关的问题。

可伸缩性有很多侧面——事务的方面、运营的方面、还有开发的方面。我们在改善一个Web系统的事务吞吐量的过程中学到了很多经验，本文总结了其中若 干关键的最佳实践。可能很多最佳实践你会觉得似曾相识，也可能有素未谋面的。这些都是开发和运营eBay网站的众人的集体经验结晶。

最佳实践 #1：按功能分割

相关的功能部分应该合在一起，不相关的功能部分应该分割开来——不管你把它叫做SOA、功能分解还是工程秘诀。而且，不相关的功能之间耦合程度越松散，就越能灵活地独立伸缩其中的一部分。

在编码层次，我们无时不刻都在运用这条原则。JAR文件、包、Bundle等等，都是用来隔离和抽象功能的机制。

在应用层次，eBay将不同的功能划分成几个应用程序池。销售功能由一组应用服务器运行，投标功能由另一组负责，搜索又是另外一组服务器。我们把总 共约16,000台应用服务器分成220个池。这样就可以根据某项功能的资源消耗，单独地伸缩其中一个池。我们也因此得以进一步隔离及合理化资源依赖关系 ——比如销售池只需要访问后台资源的一个相对较小的子集。

在数据库层次，我们也采取同样的做法。eBay没有无所不包的单一数据库，相反我们有一组数据库主机存放用户数据、一组存放商品数据、一组存放购买数据……总共1000个逻辑数据库分布在400台物理主机上。同样，这种做法让我们得以单独为某一类数据伸缩其数据库设施。

最佳实践 #2：水平切分

按功能分割对我们的帮助很大，但单凭它还不足以得到完全可伸缩的架构。即使将功能一一解耦，单项功能的资源需求随着时间增长，仍然有可能超出单一系 统的能力。我们常常提醒自己，“没有分割就没有伸缩”。在单项功能内部，我们需要能把工作负载分解成许多我们有能力驾驭的小单元，让每个单元都能维持良好 的性能价格比。这就是水平分割出场的时候了。

在应用层次，由于eBay将各种交互都设计成无状态的，所以水平分割是轻而易举之事。用标准的负载均衡服务器来路由进入的流量。所有应用服务器都是 均等的，而且任何服务器都不会维持事务性的状态，因此负载均衡可以任意选择应用服务器。如果需要更多处理能力，只需要简单地增加新的应用服务器。

数据库层次的问题比较有挑战性，原因是数据天生就是有状态的。我们会按照主要的访问路径对数据作水平分割（或称为“sharding”）。例如用户 数据目前被分割到20台主机上，每台主机存放1/20的用户。随着用户数量的增长，以及每个用户的数据量增长，我们会增加更多的主机，将用户分散到更多的 机器上去。商品数据、购买数据、帐户数据等等也都用同样的方式处理。用例不同，我们分割数据的方案也不同：有些是对主键简单取模（ID尾数为1的放到第一 台主机，尾数为二的放到下一台，以此类推），有些是按照ID的区间分割（1-1M、1-2M等等），有些用一个查找表，还有些是综合以上的策略。不过具体 的分割方案如何，总的思想是支持数据分割及重分割的基础设施在可伸缩性上远比不支持的优越。

最佳实践 #3：避免分布式事务

看到这里，你可能在疑惑按功能划分数据和水平划分数据的实践如何满足事务要求。毕竟，几乎任何有意义的操作都要更新一个以上的实体——立即就可以举 出用户和商品的例子。正统的广为人知的答案是：建立跨资源的分布式事务，用两段式提交来保证要么所有资源全都更新，要么全都不更新。很不幸，这种悲观方案 的成本很可观。伸缩、性能和响应延迟都受到协调成本的反面影响，随着依赖的资源数量和客户数量的上升，这些指标都会以几何级数恶化。可用性亦受到限制，因 为所有依赖的资源都必须就位。实用主义的答案是，对于不相关的系统，放宽对它们的跨系统事务的保证。

左右逢源是办不到的。保证跨多个系统或分区之间的即时的一致性，通常既无必要，也不现实。Inktomi的Eric Brewer十年前提出的CAP公理是这样说的：分布式系统的三项重要指标——一致性（Consistency）、可用性（Availability）和 分区耐受性（Partition-tolerance）——在任意时刻，只有两项能同时成立。对于高流量的网站来说，我们必须选择分区耐受性，因为它是实 现可伸缩的根本。对于24x7运行的网站，选择可用性也是理所当然的。于是只好放弃即时一致性（immediate consistency）。

在eBay，我们绝对不允许任何形式的客户端或者分布式事务——因此绝不需要两段式提交。在某些经过仔细定义的情形下，我们会将作用于同一个数据库 的若干语句捆绑成单个事务性的操作。而对于绝大部分操作，单条语句是自动提交的。虽然我们故意放宽正统的ACID属性，以致不能在所有地方保证即时一致 性，但现实的结果是大部分系统在绝大部分时间都是可用的。当然我们也采用了一些技术来帮助系统达到最终的一致性（eventual consistency）：周密调整数据库操作的次序、异步恢复事件，以及数据核对（reconciliation）或者集中决算（settlement batches）。具体选择哪种技术要根据特定用例对一致性的需求来决定。

对于架构师和系统的设计者来说，关键是要明白一致性并非“有”和“没有”的单选题。现实中大多数的用例都不要求即时一致性。正如我们经常根据成本和其他压力因素来权衡可用性的高低，一致性也同样可以量体裁衣，根据特定操作的需要而保证适当程度的一致性。 

最佳实践 #4：用异步策略解耦程序

提高可伸缩性的另一项关键措施是积极地采取异步策略。如果组件A同步调用组件B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各部分 必须共同进退——要伸缩A必须同时伸缩B。同步调用的组件在可用性方面也面临着同样的问题。我们回到最基本的逻辑：如果A推出B，那么非B推出非A。也就 是说，若B不可用，则A也不可用。如果反过来A和B的联系是异步的，不管是通过队列、多播消息、批处理还是什么其他手段，它们就可以分别地伸缩。而且，此 时A和B的可用性特征是相互独立的——即使B受困或者死掉，A仍然能够继续前进。

整个基础设施从上到下都应该贯彻这项原则。即使在单个组件内部也可通过SEDA（分阶段的事件驱动架构，Staged Event-Driven Architecture）等技术实现异步性，同时保持一个易于理解的编程模型。组件之间也遵守同样的原则——尽可能避免同步带来的耦合。在多数情况下， 两个组件在任何事件中都不会有直接的业务联系。在所有的层次，把过程分解为阶段（stages or phases），然后将它们异步地连接起来，这是伸缩的关键。

最佳实践 #5：将过程转变为异步的流

用异步的原则解耦程序，尽可能将过程变为异步的。对于要求快速响应的系统，这样做可以从根本上减少请求者所经历的响应延迟。对于网站或者交易系统， 牺牲数据或执行的延迟时间（完成全部工作的实践）来换取用户的延迟时间（用户得到响应的时间）是值得的。活动跟踪、单据开付、决算和报表等处理过程显然都 应该属于后台活动。主要用例过程中常常有很多步骤可以进一部分解成异步运行。任何可以晚点再做的事情都应该晚点再做。

还有一个同等重要的方面认识到的人不多：异步性可以从根本上降低基础设施的成本。同步地执行操作迫使你必须按照负载的峰值来配备基础设施——即使在 任务最重的那一天里任务最重的那一秒，设施也必须有能力立即完成处理。而将昂贵的处理过程转变为异步的流，基础设施就不需要按照峰值来配备，只需要满足平 均负载。而且也不需要立即处理所有的请求，异步队列可以将处理任务分摊到较长的时间里，因而起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从 异步处理中得益。

最佳实践 #6：虚拟化所有层次

虚拟化和抽象化无所不在，计算机科学里有一句老话：所有问题都可以通过增加一个间接层次来解决。操作系统是对硬件的抽象，而许多现代语言所用的虚拟 机又是对操作系统的抽象。对象-关系映射层抽象了数据库。负载均衡器和虚拟IP抽象了网络终端。当我们通过分割数据和程序来提高基础设施的可伸缩性，为各 种分割增加额外的虚拟层次就成为重中之重。

在eBay，我们虚拟化了数据库。应用与逻辑数据库交互，逻辑数据库再按照配置映射到某个特定的物理机器和数据库实例。应用也抽象于执行数据分割的 路由逻辑，路由逻辑会把特定的记录（如用户XYZ）分配到指定的分区。这两类抽象都是在我们自己开发的O/R层上实现的。这样虚拟化之后，我们的运营团队 可以按需要在物理主机群上重新分配逻辑主机——分离、合并、移动——而完全不需要接触应用程序代码。

搜索引擎同样是虚拟化的。为了得到搜索结果，一个聚合器组件会在多个分区上执行并行的查询，但这个高度分割的搜索网格在客户看来只是单一的逻辑索引。

以上种种措施并不只是为了程序员的方便，运营上的灵活性也是一大动机。硬件和软件系统都会故障，请求需要重新路由。组件、机器、分区都会不时增减、 移动。明智地运用虚拟化，可使高层的设施对以上变化难得糊涂，你也就有了腾挪的余地。虚拟化使基础设施的伸缩成为可能，因为它使伸缩变成可管理的。

最佳实践 #7：适当地使用缓存

最后要适当地使用缓存。这里给出的建议不一定普遍适用，因为缓存是否高效极大地依赖于用例的细节。说到底，要在存储约束、对可用性的需求、对陈旧数 据的容忍程度等条件下最大化缓存的命中率，这才是一个高效的缓存系统的最终目标。经验证明，要平衡众多因素是极其困难的，即使暂时达到目标，情况也极可能 随着时间而改变。

最适合缓存的是很少改变、以读为主的数据——比如元数据、配置信息和静态数据。在eBay，我们积极地缓存这种类型的数据，并且结合使用“推”和“ 拉”两种方法保持系统在一定程度上的更新同步。减少对相同数据的重复请求能达到非常显著的效果。频繁变更、读写兼有的数据很难有效地缓存。在eBay，我 们大多有意识地回避这样的难题。我们一直不对请求间短暂存在的会话数据作任何缓存。也不在应用层缓存共享的业务对象，比如商品和用户数据。我们有意地牺牲 缓存这些数据的潜在利益，换取可用性和正确性。在此必须指出，其他网站采取了不同的途径，作了不同的取舍，也同样取得了成功。

好东西也会过犹不及。为缓存分配的内存越多，能用来服务单个请求的内存就越少。应用层常常有内存不足的压力，因此这是非常现实的权衡。更重要的一 点，当你开始依赖于缓存，那么主要系统就只需要满足缓存未命中时的处理要求，自然而然你就会想到可以削减主要系统。但当你这样做之后，系统就完全离不开缓 存了。现在主要系统没办法直接应付全部流量，也就是说网站的可用性取决于缓存能否100%正常运行——潜在的危局。哪怕是例行的操作，比如重新配置缓存资 源、把缓存移动到别的机器、冷启动缓存服务器，都有可能引发严重的问题。

做得好，缓存系统能让可伸缩性的曲线向下弯曲，也就是比线性增长还要好——后续请求从缓存中取数据比从主存储取数据成本低廉。反过来，缓存做得不好 会引入相当多额外的经常耗费，也会妨碍到可用性。我还没见过哪个系统没机会让缓存大展拳脚的，关键是要根据具体情况找到适当缓存策略。

总结

可伸缩性有时候被叫做“非功能性需求”，言下之意是它与功能无关，也就比较不重要。这么说简直错到了极点。我的观点是，可伸缩性是功能的先决条件——优先级为0的需求，比一切需求的优先级都高。

希望以上最佳实践能对你有用，希望能帮助你从新的角度审视你的系统，无论其规模如何。

参考

• eBay's Architectural Principles (video)
• Werner Vogels on scalability
• Dan Pritchett on You Scaled Your What?
• The Coming of the Shard
• Trading Consistency for Availability in Distributed Architectures
• Eric Brewer on the CAP Theorem
• SEDA: An Architecture for Well-Conditioned, Scalable Internet Services

关于作者

Randy Shoup是eBay的杰出架构师。从2004年起担任eBay搜索基础设施的主要架构师。在加入eBay之前，他是Tumbleweed Communications公司的总架构师，也曾在Oracle和Informatica担任多个软件开发和架构的职位。

他经常在业界的会议上讲授可伸缩性和架构模式。

阅读英文原文：Scalability Best Practices: Lessons from eBay

1. create or replace trigger TRI_PrintTest   
2. before delete or insert or update on TEST_EXAM　　--触发事件   
3. for each row　　　　　　　　　　　　　　　　　　-- 每修改一行都需要调用此过程   
4. begin  
5.      dbms_output.put_line(:new.IDNEW);     --IDNEW字段更新后的值   
6.      dbms_output.put_line(:old.IDNEW);       --IDNEW字段更新前的值   
7. end;  

原IDNEW字段是1时，

使用

update TEST_EXAM set IDNEW=5 where SN='5454';

则打印结果为：

5
1