从myspace数据库看分布式系统数据结构变迁

服务器 专栏收录该内容
12 篇文章 0 订阅

从myspace数据库看分布式系统数据结构变迁

http://smb.pconline.com.cn/database/0808/1403100.html
[08-29 14:33:40]出处:pconline作者:责任编辑:heyaorong
  MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素,但是我们却抛弃这一点,而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。
  MySpace信息系统发展历程:
  第一代架构—添置更多的Web服务器
  MySpace最初的系统很小,只有两台Web服务器(分担处理用户请求的工作量)和一个数据库服务器(所有数据都存储在这一个地方)。那时使用的是 Dell双CPU、4G内存的系统。在早期阶段,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期,在 MySpace用户数增长到五十万后,其数据库服务器已经开始疲于奔命了。
  第二代架构—增加数据库服务器
  与增加Web服务器不同,增加数据库并没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下让多个数据库分担压力。
  MySpace运行在三个SQL Server数据库服务器上—一个为主,所有的新数据都向它提交,然后由它复制到其它两个;另两个数据库服务器全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。
  这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace只需要投入新的数据库加以支持。在账户到达二百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(存储区域网络)—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而,当用户继续增加到三百万后,垂直分割策略也变得难以维持下去。
  第三代架构—转到分布式计算架构
  几经折腾,最终,MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
  既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
  第四代架构—求助于微软方案
  2005年早期,账户达到九百万,MySpace开始用微软的C#编写 ASP.NET程序。在收到一定成效后,MySpace开始大规模迁移到ASP.NET。用户达到一千万时,MySpace再次遭遇存储瓶颈问题。SAN 的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
  第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 2005
  2005年春天,MySpace账户达到一千七百万,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。
  2005年中期,服务账户数达到两千六百万时,MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。
  事实上,MySpace的Web服务器和数据库仍然经常发生超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示,他们不得不在论坛抱怨不停……
  MySpace正是在这样不断重构站点软件、数据库和存储系统中,才一步步走到今天。事实上,MySpace已经成功解决了很多系统扩展性问题,其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定,但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚,尽可能把事情做到最好。
  虽然自2005年早期,站点账户数超过7百万后,系统架构到目前为止保持了相对稳定,但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚。
  里程碑一:50万账户
  MySpace最初的系统很小,只有两台Web服务器和一个数据库服务器。那时使用的是Dell双路CPU、4G内存的系统。
  单个数据库就意味着所有数据都存储在一个地方,再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样,三服务器架构很快不堪重负。此后一个时期内,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
  但到在2004年早期,MySpace用户数增长到50万后,数据库服务器也已开始汗流浃背。
  但和Web服务器不同,增加数据库可没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下,让多个数据库分担压力。
  在第二代架构中,MySpace运行在3个SQL Server数据库服务器上——一个为主,所有的新数据都向它提交,然后由它复制到其他两个;另两个全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。

        里程碑二:1-2百万账户
  MySpace注册数到达1百万至2百万区间后,数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中,距离上次数据库系统调整不过数月。用户的提交请求被阻塞,就像千人乐迷要挤进只能容纳几百人的夜总会,站点开始遭遇"主要矛盾",Benedetto说,这意味着 MySpace永远都会轻度落后于用户需求。
  有人花5分钟都无法完成留言,因此用户总是抱怨说网站已经完蛋了。这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。于是,站点的扩展性问题看似又可以告一段落了,可以歇一阵子。
  垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace将投入新的数据库予以支持它。账户到达2百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(Storage Area Network,存储区域网络)——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。
  里程碑三:3百万账户
  当用户继续增加到3百万后,垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立,但有些信息必须共享。在这个架构里,每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时,该条账户记录必须在9个不同数据库上分别创建。但在个别情况下,如果其中某台数据库服务器临时不可到达,对应事务就会失败,从而造成账户非完全创建,最终导致此用户的该项服务无效。
  另外一个问题是,个别应用如博客增长太快,那么专门为它服务的数据库就有巨大压力。
  2004年中,MySpace面临Web开发者称之为"向上扩展"对"向外扩展"(译者注:Scale Up和Scale Out,也称硬件扩展和软件扩展)的抉择——要么扩展到更大更强、也更昂贵的服务器上,要么部署大量相对便宜的服务器来分担数据库压力。一般来说,大型站点倾向于向外扩展,因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
  但成功地向外扩展架构必须解决复杂的分布式计算问题,大型站点如Google、Yahoo和Amazon.com,都必须自行研发大量相关技术。以Google为例,它构建了自己的分布式文件系统。
  另外,向外扩展策略还需要大量重写原来软件,以保证系统能在分布式服务器上运行。"搞不好,开发人员的所有工作都将白费",Benedetto说。因此,MySpace首先将重点放在了向上扩展上,花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说,"那时候,这个方案看似可能解决一切问题。"如稳定性,更棒的是对现有软件几乎没有改动要求。
  糟糕的是,高端服务器极其昂贵,是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且,站点架构师预测,从长期来看,即便是巨型数据库,最后也会不堪重负,Benedetto说,"换句话讲,只要增长趋势存在,我们最后无论如何都要走上向外扩展的道路。"
  因此,MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
  既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约2百万用户。Benedetto指出,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
  当然,还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后,保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大,但它只负责用户登录,功能单一,所以负荷还是比较容易控制的。
  里程碑四:9百万到1千7百万账户
  2005年早期,账户达到9百万后,MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言,吸收了C++ 和Java的优点,依托于Microsoft .NET框架(Microsoft为软件组件化和分布式计算而设计的模型架构)。ASP.NET则由编写Web站点脚本的ASP技术演化而来,是 Microsoft目前主推的Web站点编程环境。
  可以说是立竿见影, MySpace马上就发现ASP.NET程序运行更有效率,与ColdFusion相比,完成同样任务需消耗的处理器能力更小。据技术总监 Whitcomb说,新代码需要150台服务器完成的工作,如果用ColdFusion则需要246台。Benedetto还指出,性能上升的另一个原因可能是在变换软件平台,并用新语言重写代码的过程中,程序员复审并优化了一些功能流程。
  最终,MySpace开始大规模迁移到 ASP.NET。即便剩余的少部分ColdFusion代码,也从Cold-Fusion服务器搬到了ASP.NET,因为他们得到了 BlueDragon.NET(乔治亚州阿尔法利塔New Atlanta Communications公司的产品,它能将ColdFusion代码自动重新编译到Microsoft平台)的帮助。
  账户达到1千万时,MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
  原因之一是每数据库1百万账户的分割策略,通常情况下的确可以将压力均分到各台服务器,但现实并非一成不变。比如第七台账户数据库上线后,仅仅7天就被塞满了,主要原因是佛罗里达一个乐队的歌迷疯狂注册。
  某个数据库可能因为任何原因,在任何时候遭遇主要负荷,这时,SAN中绑定到该数据库的磁盘存储设备簇就可能过载。"SAN让磁盘I/O能力大幅提升了,但将它们绑定到特定数据库的做法是错误的。"Benedetto说。
  最初,MySpace通过定期重新分配SAN中数据,以让其更为均衡的方法基本解决了这个问题,但这是一个人工过程,"大概需要两个人全职工作。"Benedetto说。
  长期解决方案是迁移到虚拟存储体系上,这样,整个SAN被当作一个巨型存储池,不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
  在3PAR的系统里,仍能在逻辑上按容量划分数据存储,但它不再被绑定到特定磁盘或磁盘簇,而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时,任何空闲磁盘都可以马上完成这项工作,而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且,因为多个磁盘都有数据副本,读取数据时,也不会使SAN的任何组件过载。
  当2005年春天账户数达到1千7百万时,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。换句话说,100个用户请求同一份资料,以前需要查询数据库100次,而现在只需1次,其余都可从缓存数据中获得。当然如果页面变化,缓存的数据必须从内存擦除,然后重新从数据库获取——但在此之前,数据库的压力已经大大减轻,整个站点的性能得到提升。
  缓存区还为那些不需要记入数据库的数据提供了驿站,比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课,"我是数据库存储狂热分子,因此我总是想着将万事万物都存到数据库。"但将像会话跟踪这类的数据也存到数据库,站点将陷入泥沼。
  里程碑五:2千6百万账户
  2005年中期,服务账户数达到2千6百万时,MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急?主流看法是2005版支持64位处理器。但Benedetto说,"这不是主要原因,尽管这也很重要;主要还是因为我们对内存的渴求。"支持64位的数据库可以管理更多内存。
  更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器,能同时使用的内存最多只有4G。切换到64位,就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。

意外错误促进系统健康成长
  如果没有对系统架构的历次修改与升级,MySpace根本不可能走到今天。但是,为什么系统还经常吃撑着了?很多用户抱怨的"意外错误"是怎么引起的呢?
  原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月,超出SQL Server最大同时连接数,MySpace系统崩溃。Benedetto说,这类可能引发系统崩溃的情况大概三天才会出现一次,但仍然过于频繁了,以致惹人恼怒。一旦数据库罢工,"无论这种情况什么时候发生,未缓存的数据都不能从SQL Server获得,那么你就必然看到一个'意外错误'提示。"他解释说。
  去年夏天,MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击(黑客使用很多客户机向服务器发起大量连接请求,以致服务器瘫痪)。MySpace和其他很多顶级大站点一样,肯定会经常遭受攻击,但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则,大量 MySpace合法用户连接时也会引起服务器反击。
  "我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。"Benedetto说。最后,通过Microsoft的帮助,他们才知道该怎么通知服务器:"别开枪,是友军。"
  紧接着是在去年7月某个周日晚上,MySpace总部所在地洛杉矶停电,造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来,MySpace还有其他两个数据中心以应对突发事件,但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN,Web服务器除了恳求你耐心等待,不能提供任何服务。
  Benedetto说,主数据中心的可靠性通过下列措施保证:可接入两张不同电网,另有后备电源和一台储备有30天燃料的发电机。但在这次事故中,不仅两张电网失效,而且在切换到备份电源的过程中,操作员烧掉了主动力线路。
  2007年中,MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下,每个SAN都能负担三分之一的数据访问量。而在紧急情况下,任何一个站点都可以独立支撑整个服务,Benedetto说。
  MySpace仍然在为提高稳定性奋斗,虽然很多用户表示了足够信任且能原谅偶现的错误页面。
  "作为开发人员,我憎恶Bug,它太气人了。"Dan Tanner这个31岁的德克萨斯软件工程师说,他通过MySpace重新联系到了高中和大学同学。"不过,MySpace对我们的用处很大,因此我们可以原谅偶发的故障和错误。" Tanner说,如果站点某天出现故障甚至崩溃,恢复以后他还是会继续使用。
  这就是为什么Drew 在论坛里咆哮时,大部分用户都告诉他应该保持平静,如果等几分钟,问题就会解决的原因。Drew无法平静,他写道,"我已经两次给MySpace发邮件,而它说一小时前还是正常的,现在出了点问题……完全是一堆废话。"另一个用户回复说,"毕竟它是免费的。"Benedetto坦承100%的可靠性不是他的目标。"它不是银行,而是一个免费的服务。"他说。
  换句话说,MySpace的偶发故障可能造成某人最后更新的个人资料丢失,但并不意味着网站弄丢了用户的钱财。"关键是要认识到,与保证站点性能相比,丢失少许数据的故障是可接受的。"Benedetto说。所以,MySpace甘冒丢失2 分钟到2小时内任意点数据的危险,在SQL Server配置里延长了"checkpoint"操作——它将待更新数据永久记录到磁盘——的间隔时间,因为这样做可以加快数据库的运行。
  Benedetto说,同样,开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险,但这样做可以更快实现新功能。而且,因为进行大规模真实测试不具可行性,他们的测试通常是在仅以部分活跃用户为对象,且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试,他们做的测试通常都是针对站点。

总结一点:从myspace看更加验证,数据库是软件系统的瓶颈,而且最不可伸缩,一旦数据库成为系统瓶颈,就得动大手术,实现架构上的变迁,这是伤筋动骨,变迁人员压力巨大的。另外由于是社区,就是变迁数据丢失也没什么大不了,如果是企业那就......

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34551&message=23116484#23116484

我最欣赏Gavin King的这句话,狠狠煽了那些曾经跟随Gavin King人的耳光:
数据库成为了大多数企业应用的主要瓶颈,也成为了运行环境中最不具伸缩性的层。
PHP/Ruby的用户会说什么都不共享(share nothing)的架构照样具有很好的伸缩性,这些傻瓜真正想的是“除了数据库以外什么都不共享(Share nothing except for the database)”的架构
我先来翻译一下上面这段意思:经过大量实践证明:数据库已经成为企业计算主要性能瓶颈,因为我们大量业务计算依赖数据库,虽然,数据库可以集群,但是代价昂贵,效率不高,而且最多两台或几台,因此,数据库已经成为运行环境中最不scalable的环节。
所谓伸缩性,就是弹性,整个软件架构既支持小负载运行,也支持大负载支持,只要增加服务器(PC服务器价格是便宜)即可;没有伸缩性意思这个软件小负载可以运行,到大负载,就有天花板了,即使进行数据库性能调优(这也是不少人觉得数据库技术很重要的原因),也只是缓口气,性能调优也有天花板,单台机器挖潜力总是有限的,向下死挖的概念就造成现在很多人对数据库调优技术的依赖;其实这些人为什么不向上想想,一台不够,我再增加一台,只要配置一下即可,经过权威测试:websphere/weblogic的20台PC服务器集群性能不亚于一台SUN/IBM的中型机,性价比已经一目了然了。
跟随PHP/Ruby的那些傻瓜用户认识到这点,就开始回避,宣称:share nothing,其实这是不可能的,应用中的很多数据都是依靠反复访问同一个数据库来达到共享,所以,实质是:Share nothing except for the database,类似鸵鸟把头插入沙子,认为就可以解决问题。
那么我们看看EJB或分布式缓存是如何解决这个共享问题:因为软件业务逻辑都是基于对象的,而这些对象可以在多台websphere/weblogic/jboss之间传输,通过分布式缓存就解决了共享问题,应用逻辑不必每次都要通过数据库来分享数据,应用逻辑之间本身可以直接传输业务对象数据,以达到分享。
所以,PHP/Ruby运行环境的架构特点还都是依赖数据库的,虽然他们打着Evans DDD口号,并且声称Ruby On Rails还是最适合DDD的,到时到最后落实代码时,就露出马脚,披着羊皮的狼,批着DDD,实则是以数据库中心。这也是为什么一些程序员既认为分析设计是要采取DDD,但是数据库技术依然重要的原因,这些都是不彻底的对象程序员,他们必然遭遇对象/关系数据库带来的复杂性,然后他们错以为是语言问题,转而追寻ROR这样动态语言,希望这个新语言能解救他们,虽然ROR有类似Hibernate之类ActiveRecord等ORM框架,由于运行环境还是依赖不伸缩的数据库,当系统复杂时,他们又会碰到OO/db的不匹配,真是傻瓜了。
当然,这种畸形也许适合一些中庸的中国程序员(对象和数据库两个都要)。不是我在大喊数据库时代过去时,那么多人反对,反对弱化数据库,因为他们脑子里数据库为王已经根深蒂固,就像一个保皇派,保数据库这个皇帝,大权不能旁落。
另外:我一直提出的Open Session In View是一个在Spring中无法解决的问题,是一个反模式,这点在Seam中也得到了解决,这说明是一个真理,我喜欢在Jdon说真话,很多言论都可以查询,2003年至今我没有发现严重的错误观点和预测,唯一没料到的是:PHP比我想象中顽强。

posted @ 2009-07-15 21:31 cxccbv 阅读(305) | 评论(0) | 编辑

数据库时代的终结

板桥里人 http://www.jdon.com 2005/04/28

  以数据库为核心的软件时代已经过去,数据库时代早已结束,当我看到J2EE征途中那么多人在对象和数据库之间彷徨痛苦ing的时候,我想我该出来喊一声了。

  其实这句话在几年前肯定有人喊过,因为中间件时代的来临,实际意味着数据库时代终结,正所谓一山无二虎:如果你重视数据库,你的J2EE系统就无法完全 OO,只有你忽视数据库,你的系统才有可能完全迈向OO,至于数据库性能调优等特定功能都可交由EJB容器或O/R Mapping工具实现。

  很多年前,包括我自己在内的大部分企业程序员都是从数据库开始我们的职业生涯,最早的是dBase/FoxPro,后来有了 SQL系列数据库, Oracle将数据库时代推向了顶峰。

  每当有一个新项目时,第一步就是首先设计出数据表结构(Table Schema),然后开始使用SQL语句实现业务逻辑,这种开发模式一直重复,就是后来加入了DelPhI/VB,他们也只是承担图形显示实现,这种C /S结构带来最大问题是:非常难于维护,修改起来,迁一动百。

  软件的生命在于运动,当它需要发展时,最棒的软件人员如果对他也束手无策,这是谁的悲哀?

  现在更多人开始接受B/S结构,但是他们中很多人还没有真正明白为什么需要B/S结构,B/S代表的多层架构才是真正目的(因此,伪多层的B/S系统遍地皆是)。

  多层架构实际是将以前系统中的显示功能、业务运算功能和数据库功能完全分开,杜绝彼此的耦合与影响,从而实现松耦合和良好的可维护性。

  一. 从设计上说:由于实现层次完全分离,业务运算功能成为一种中间功能(中间层),它不依赖具体的表现层技术(Jsp/Html applet等),也不依赖具体数据库技术(Oracle/SQL Server),业务运算功能运行在J2EE应用服务器中,当我们的业务运算功能不再依赖数据库时,是否意味着数据库已经不是重点?

  二. 当然,多层结构带来了性能问题:客户端访问数据库中的数据时,通常需要经过多个层次,非常耗费性能,如何尽量减少数据库访问是J2EE应用系统首要解决的问题,使用存储过程并没有解决这个问题,存储过程的执行还是属于后端,并没有缩短客户端请求所要经历的坎坷路途。

  解决性能问题的根本解决之道是使用对象缓存,现在, 64位CPU提供的巨大内存空间为单台缓存计算提供了硬件基础,更重要的是,这种缓存计算是可伸缩的,通过集群缓存机制(如JBossCache), 通过增加应用服务器的数量,可以提高整个业务逻辑层的缓存计算能力,抛弃过去那种为内存斤斤计较的老思维吧。

  三. 在系统分析之初是否首先需要数据表设计呢?回答是否定的, 以UML为代表面向对象的分析设计方法已经成为强大工具,随着面向模型驱动分析设计(MDA/MDD/DDD)的普及, 面向数据库分析方法正在逐步被抛弃,拥有深厚传统数据库分析习惯的程序员必须面对和接受这种挑战。

  纵观整个J2EE系统开发过程,数据库已经从过去的中心位置降为一种纯技术实现,数据库只是状态持久化的一种手段(文件是另外一种实现手段);什么是持久化?这是相对于内存缓存状态而言,持久化就是当内存断电情况下能永久保存状态数据,但是如果J2EE应用服务器是7X24小时集群运行;几乎永不当机,是否有持久化的必要呢?

  很显然,数据库已经沦为与操作系统中文件系统同样的层面,以它为中心的时代真的结束了,IBM早期将DB2数据库开源已经强烈向我们昭示这点。

  对于J2EE初学者来说,尽早抛弃过去的两种影响:过程语言编程习惯和以数据库为中心的设计习惯,从全新的面向对象角度(OOA、OOD和OOP、AOP)来设计开发你的J2EE系统,J2EE设计开发三件宝:Model、Patterns和Framework

  以上不只是理论,而是我每天正在做的,如果你也是或赞同请广为传播,唤醒更多彷徨痛苦的初学者。

posted @ 2009-07-15 21:25 cxccbv 阅读(35) | 评论(0) | 编辑

数据库已死

板桥里人 http://www.jdon.com 2008/09/03

  现代软件和以往传统软件主要区别在于:现代软件基于internet互联网技术,运行于开放的网络环境,不象传统软件只是运行在封闭的局域网,运行环境的区别就决定了软件操作用户的多少,在一个开放互联网环境,你的软件系统用户是不断增长,特别是那些对所有人群开放的社区网站系统,更是承受前所未有的访问负载。那么,这些软件系统承受的压力主要会集中在软件的哪个环节呢?如果你使用传统软件的设计思路,那么无疑压力都集中在数据库上。

  随着用户的爆发量增长,在某个凌晨醒来时,你发现:数据库已死。

  传统软件系统实则应该叫数据库软件系统,是一个数据库系统,开发这样的系统非常简单,成本也非常低廉,只要根据需求先设计好数据表结构,然后,就找一些大学毕业生写大量SQL语句,虽然还使用 JAVA/PHP/.NET等语言,但实际上这些语言只是将SQL送往数据库执行的运输工,没有什么价值和地位。

  所以,这样的系统运行在互联网环境下以后,主要负载就集中在数据库的SQL运行上,也就是说:整个软件系统性能关键点就集中在数据库上了,数据库是性能主角,是王者;虽然你购置了昂贵的Websphere/weblogic等应用服务器,但是由于Java只是运输工,根本起不到性能上负载分担的作用。

  著名的社区网站MySpace就是因为一个好的idea,用户疯狂增长,但是系统却不能平滑承受增长的用户访问,这些用户访问网站缓慢、无法访问甚至丢失数据,他们经过几次伤筋动骨的架构升级,在微软SQLServer直接技术支持下,好容易才勉强应付过去。看看他们痛苦经历,你是否也愿意再来一次呢?详细情况: http://www.jdon.com/jivejdon/thread/34601.html

  从中可以看出,数据库性能微调和挖潜总是有限度的,对数据库性能优化提高性能的步伐永远赶不上用户增长量,有人也提出数据库集群的概念,其实数据库集群是一个骗人概念,一般只是备份,在集群数量和failover上有制约,否则,数据库巨头Oracle不会跑到JavaEE阵营摇旗呐喊,还最早推出EJB3服务器,并扬言要收购JavaEE过去老大 Bea Weblogic。

  很显然,数据库成已经为软件系统的主要性能瓶颈了,单纯依靠数据库自救的方式已经行不通,是宣布数据库退出主角时候了,那么由谁来宣布:教皇数据库已死?无疑是Java。

  Java社区早在本世纪初就提出中间件概念,用以取代数据库地位,实则就是将软件系统主要负载从数据库上转移到中间件服务器上,分担负载。 也就是说:Java社区提出:既然数据库已经成为瓶颈,修修补补也无济于事,不如放弃它,不再依赖它。

  也就是说:Java不再做SQL的运输工,不再是跑龙套的了,而是主角,那么如何让Java成为主角呢?那必须依赖对象这个概念,对象是生活在中间件服务器内存中,它又是数据库数据的业务封装,它和数据库有着 千丝万缕的关系,但是它又和关系数据库存在天然矛盾,两者水火不容。

  过去,我们是将业务逻辑写成SQL送往数据库执行,导致数据库成为业务逻辑主要运行瓶颈,那么,如果我们将业务逻辑用对象概念表达,而不是SQL,那么我们的业务逻辑就围绕内存中的对象反复计算,这样,负载不是集中在对象运行的中间件服务器上(也就是应用服务器Weblogic/websphere/JBoss/Tomcat)?而对象/中间件都是用Java 语言表达的,无疑,这样的架构,Java才成为主角。

  再进一步想想:如果我们从软件系统开始之初,就使用对象分析设计,不与数据库沾边,整个流程就完全OO,分析设计直至代码都摆脱了数据库影响,这个流程如下:

  分析建模 细化设计(通过Evans DDD) 架构设计 代码实现 调试测试 部署运行。
  那么数据库在什么时候建立呢?数据库表结构的创建可以延缓到部署运行时,由Hibernate/EJB CMP/JPA等ORM技术自动实现。这样,整个上游环节就不涉及数据库技术,而是使用更符合自然的表达OO方式,软件质量就更高了。我在J道网站已经大量阐述了如何从OO分析到OO实现的过程,包括我的Jdon框架也直接支持这样一个自然方式。

  现在,很多人已经理解,分析设计要用OO,但是数据库是运行阶段缺少不了的,确实,这是正确观点,我们夺取数据库的王位,不是将它打倒,只是理性和平移交权力重心而已,数据库退出主角地位,让位于Java中间件,也预示着过去数据库为王的时代的结束, 但是数据库会和操作系统一样,成为我们现代软件系统一个不可缺少重要的基础环节。

  正是基于这样事实,虽然我早在2005年喊出“数据库时代的终结一文,回帖长达几百贴, 大部分是怀疑论,不信论,其实2003年国外TSS就有一篇“给数据库休息吧” (休息不代表退休,而是退居幕后,就象操作系统作用一样),由此可见,由于传统观点影响和不及时与国际新思想同步,国内数据库保皇派还是有相当人数的。我 BanQ人微言轻,抛出这些观点被保皇派讥讽为所疯话,那么看看,著名ORM框架Hibernate和SEAM框架创始人Gavin King的一段观点:

  In almost all enterprise applications, the database is the primary bottleneck, and the least scalable tier of the runtime environment. 数据库成为了大多数企业应用的主要瓶颈,也成为了运行环境中最不具伸缩性的层。... PHP/Ruby的用户会说什么都不共享(share nothing)的架构照样具有很好的伸缩性,.... 这些傻瓜真正想的是“除了数据库以外什么都不共享(Share nothing except for the database)”的架构。更多参看这里

  所谓伸缩性,就是弹性,整个软件架构既支持小负载运行,也支持大负载支持,只要增加服务器即可;由于软件系统负载已经从SQL转移到内存中的对象上,那么我们就可以通过增加这些应用服务器数量,通过分布式计算甚至云计算,达到业务对象在多台应用服务器之间传递共享,而不必通过数据库这个环节,既减轻数据库负载,又能轻松扩充性能,不必走集中试大型主机之路,只要添置低廉PC服务器即可。经过权威测试:websphere/weblogic的20台PC服务器集群性能不亚于一台SUN/IBM的中型机,性价比已经一目了然了。

  JavaEE的服务器的集群相对于Linux等操作系统集群的好处在于:JavaEE集群能够针对某个繁忙负载大的具体业务功能进行集群,换句话说: 就是做到精确制导,精确解决问题,而显然,Linux操作系统的集群则无法直至业务核心的。

  从另外一个方面看:虽然现在PHP号称走上对象路线,Ruby的铁轨开始铺进企业,但是他们的运行环境实则依赖数据库的, 特别是Ruby On Rails还是最适合Evans DDD对象建模路线,但是目前来讲还是"披着羊皮的狼",批着DDD,实则是以数据库中心。当然相信 ROR等将来会提供分布式计算环境,但是JavaEE在2002年时就通过EJB以及分布式缓存成熟稳定地提供分布式计算的中间件,并且已经大量成熟应用。

  本文结束以前,我相信大家明白,在众多语言平台竞争中,为什么Java能够击败过去拳王数据库,夺得新的拳王冠军,以及他的特点所在。有人可能会说:你忘记谈.NET了,这个不用我回答你,用微软中国董事长张亚勤的话回答:8年前.NET战略很天真, 你会将你的重要业务企业计算依赖一个很天真不成熟的技术吗?除非你自己也很天真:)。

posted @ 2009-07-15 21:24 cxccbv 阅读(32) | 评论(0) | 编辑

系统缓存全解析

http://www.cnblogs.com/ltp/archive/2009/06/30/1514311.html

有时候总听到网友说网站运行好慢,不知如何是好;有时候也总见到一些朋友写的网站功能看起来非常好,但访问性能却极其的差。没有“勤俭节约”的意识,势必会造成“铺张浪费”。如何应对这种情况,充分利用系统缓存则是首要之道。

    系统缓存有什么好处呢?举个简单的例子,你想通过网页查询某些数据,而这些数据并非实时变化,或者变化的时间是有期限的。例如查询一些历史数据。那么每个用户每次查的数据都是一样的。如果不设置缓存,ASP.NET也会根据每个用户的请求重复查询n次,这就增加了不必要的开销。所以,可能的情况下尽量使用缓存,从内存中返回数据的速度始终比去数据库查的速度快,因而可以大大提供应用程序的性能。毕竟现在内存非常便宜,用空间换取时间效率应该是非常划算的。尤其是对耗时比较长的、需要建立网络链接的数据库查询操作等。

缓存功能是大型网站设计一个很重要的部分。由数据库驱动的Web应用程序,如果需要改善其性能,最好的方法是使用缓存功能。

       系统缓存全解析文章索引

15.4.1 缓存的分类

     从分布上来看,我们可以概括为客户端缓存和服务器端缓存。如图15-1所示:

图15-1 缓存的分类

客户端缓存—— 这点大家都有直观的印象。比如你去一个新的网站,第一次可能要花一阵子时间才能载入整个页面。而以后再去呢,时间就会大大的缩短,原因就在于这个客户端缓存。现在的浏览器都比较智能,它会在客户机器的硬盘上保留许多静态的文件,比如各种gif,jpeg文件等等。等以后再去的时候,它会尽量使用本地缓存里面的文件。只有服务器端的文件更新了,或是缓存里面的文件过期了,它才会再次从服务器端下载这些东西。很多时候是IE替我们做了这件事情。

服务器端缓存—— 有些东西没法或是不宜在客户端缓存,那么我们只好在服务器端想想办法了。服务器端缓存从性质上看,又可以分为两种。

(1)静态文件缓存

    好多页面是静态的,很少改动,那么这种文件最适于作静态缓存。现在的IIS 6.0这部分内容是直接存放在Kernel的内存中,由HTTP.SYS直接管理。由于它在Kernel Space,所以它的性能非常的高。用户的请求如果在缓存里面,那么HTTP.SYS直接将内容发送到network driver上去,不需要像以前那样从IIS的User space的内存copy到Kernel中,然后再发送到TCP/IP stack上。Kernel level cache几乎是现在高性能Web server的一个必不可少的特性。

(2)动态缓存

     动态缓存是比较有难度的。因为你在缓存的时候要时刻注意一个问题,那就是缓存的内容是不是已经过时了。因为内容过时了可能会有很严重的后果。比如网上买卖股票的网站。你给别人提供的价格是过时的,那人家非砍了你不可。缓存如何发现自己是不是过时就是一个非常复杂的问题。

    在ASP.NET中,常见的动态缓存主要有以下几种手段:

  Ø 传统缓存方式

  Ø 页面输出缓存。

  Ø 页面局部缓存。

  Ø 利用.NET提供的System.Web.Caching 缓存。

  Ø 缓存依赖。

15.4.2 传统缓存方式--页面输出缓存

比如将可重复利用的东西放到Application或是Session中去保存。

Session["Style"] = val;
Application["Count"] = 0;

页面输出缓存是最为简单的缓存机制,该机制将整个ASP.NET页面内容保存在服务器内存中。当用户请求该页面时,系统从内存中输出相关数据,直到缓存数据过期。在这个过程中,缓存内容直接发送给用户,而不必再次经过页面处理生命周期。通常情况下,页面输出缓存对于那些包含不需要经常修改内容的,但需要大量处理才能编译完成的页面特别有用。需要读者注意的是,页面输出缓存是将页面全部内容都保存在内存中,并用于完成客户端请求。

在ASP.NET中页面缓存的使用方法非常的简单,只需要在aspx页的顶部加这样一句声明即可:

<%@ OutputCache Duration="60" VaryByParam="none" %>

Duration

缓存的时间(秒)。这是必选属性。如果未包含该属性,将出现分析器错误。

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="CacheWebApp._16_4_3.WebForm1" %>

<%@ OutputCache Duration="60" VaryByParam="none" %>

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>页面缓存示例</title>

</head>

<body>

<form id="form1" runat="server">

<div>

<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

</div>

</form>

</body>

</html>

后台代码:

protected void Page_Load(object sender, EventArgs e)

{

if (!IsPostBack)

{

Label1.Text = DateTime.Now.ToString();

}

}

如果不加<%@ OutputCache Duration="60" VaryByParam="none" %>,每次刷新页面上的时间每次都是在变。而加了缓存声明以后,每次刷新页面的时间并不变化,60秒后才变化一次,说明数据被缓存了60秒。

VaryByParam

是指页面根据使用 POST 或 GET 发送的名称/值对(参数)来更新缓存的内容,多个参数用分号隔开。如果不希望根据任何参数来改变缓存内容,请将值设置为 none。如果希望通过所有的参数值改变都更新缓存,请将属性设置为星号 (*)。

例如: http://localhost:1165/16-4-3/WebForm1.aspx?p=1
则可以在WebForm1.aspx页面头部声明缓存:<%@ OutputCache Duration="60" VaryByParam="p" %>

以上代码设置页面缓存时间是60秒,并根据p参数的值来更新缓存,即p的值发生变化才更新缓存

如果一直是WebForm1.aspx?p=1访问该页,则页面会缓存当前数据,当p=2时又会执行后台代码更新缓存内容。

如果有多个参数时,如:http://localhost:1165/16-4-3/WebForm1.aspx?p=1&n=1

可以这样声明:<%@ OutputCache Duration="60" VaryByParam="p;n" %>

除此之外,@OutputCache 还有一些其他的属性。@OutputCache指令中的属性参数描述如下:

<%@ OutputCache Duration="#ofseconds"

Location="Any | Client | Downstream | Server | None | 

ServerAndClient "

Shared="True | False"

VaryByControl="controlname"

VaryByCustom="browser | customstring"

VaryByHeader="headers"

VaryByParam="parametername"

CacheProfile="cache profile name | ''"

NoStore="true | false"

SqlDependency="database/table name pair | CommandNotification"

%>

CacheProfile

用于调用Web.config配置文件中设置的缓存时间。这是可选属性,默认值为空字符 ("")。

例如:

在Web.config中加入配置:

<system.web>

<caching>

<outputCacheSettings>

<outputCacheProfiles>

<add name="CacheTest" duration="50" />

</outputCacheProfiles>

</outputCacheSettings>

</caching>

</system.web>

页面中声明:

<%@ OutputCache CacheProfile="CacheTest" VaryByParam="none" %>

注意:

包含在用户控件(.ascx 文件)中的 @ OutputCache 指令不支持此属性。在页中指定此属性时,属性值必须与 outputCacheSettings 节下面的 outputCacheProfiles 元素中的一个可用项的名称匹配。如果此名称与配置文件项不匹配,将引发异常。

如果每个页面的缓存时间相同,则不需要每个页面设置,而是通过统一一个地方控制,这样就可以更好的统一控制所有页面的缓存时间。如果想改变缓存时间,只需要改一下web.config的配置信息即可,而不用每个页面去修改。

VaryByControl

通过用户控件文件中包含的服务器控件来改变缓存(值是控件ID,多控件用分号隔开)。

在 ASP.NET 页和用户控件上使用 @ OutputCache 指令时,需要该属性或 VaryByParam 属性。

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm2.aspx.cs" Inherits="CacheWebApp._16_4_3.WebForm2" %>

<%@ OutputCache Duration="60" VaryByParam="none" VaryByControl="DropDownList1" %>


<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>根据控件页面缓存</title>

</head>

<body>

<form id="form1" runat="server">

<div>

<%=DateTime.Now %>

<br>

<asp:DropDownList ID="DropDownList1" runat="server">

<asp:ListItem>beijing</asp:ListItem>

<asp:ListItem>shanghai</asp:ListItem>

<asp:ListItem>guangzhou</asp:ListItem>

</asp:DropDownList>

<asp:Button ID="Button1" runat="server" Text="提交" />

</div>

</form>

</body>

</html>

以上代码设置缓存有效期是60秒,并且页面不随任何GET或POST参数改变(即使不使用VaryByParam属性,但是仍然需要在@ OutputControl指令中显式声明该属性)。如果用户控件中包含ID属性为“DropDownList1”的服务器控件(例如下拉框控件),那么缓存将根据该控件的变化来更新页面数据

页面输出缓存API

Response类的Cache属性用于获取页面缓存策略。该方式的核心是调用System.Web.HttpCachePolicy。该类主要包含用于设置缓存特定的HTTP标头的方法和用于控制ASP.NET 页面输出缓存的方法。与.NET Framework 1.x中的HttpCachePolicy类相比,.NET Framework 2.0中的HttpCachePolicy类得到了扩充和发展。主要是增加了一些重要方法,例如,SetOmitVarStar方法等。由于 HttpCachePolicy类方法众多,下面简要说明几个常用方法。

SetExpires方法

用于设置缓存过期的绝对时间。它的参数是一个DataTime类的实例,表示过期的绝对时间。

protected void Page_Load(object sender, EventArgs e)

{

// 通过API设置缓存

//相当于@OutputCache指令中的Duration属性

Response.Cache.SetExpires(DateTime.Now.AddSeconds(10));

Response.Cache.SetExpires(DateTime.Parse("6:00:00PM"));

}

如上代码,第一行代码表示输出缓存时间是60秒,并且页面不随任何GET或POST参数改变,等同于“<%@ OutputCache Duration="60" VaryByParam="none" %>”。第二行代码设置缓存过期的绝对时间是当日下午6时整

SetLastModified方法

用于设置页面的Last-Modified HTTP标头。Last-Modified HTTP标头表示页面上次修改时间,缓存将依靠它来进行计时。如果违反了缓存限制层次结构,此方法将失败。该方法的参数是一个DataTime类的实例。

SetSlidingExpiration方法

该方法将缓存过期从绝对时间设置为可调时间。其参数是一个布尔值。当参数为true时,Cache-Control HTTP标头将随每个响应而更新。此过期模式与相对于当前时间将过期标头添加到所有输出集的IIS配置选项相同。当参数为False时,将保留该设置,且任何启用可调整过期的尝试都将静态失败。此方法不直接映射到HTTP标头。它由后续模块或辅助请求来设置源服务器缓存策略。

SetOmitVaryStar方法

ASP.NET 2.0新增的方法。用于指定在按参数进行区分时,响应是否应该包含vary:*标头。方法参数是一个布尔值,若要指示HttpCachePolicy不对其VaryByHeaders属性使用*值,则为true;否则为false。

SetCacheability方法

    用于设置页面的Cache-Control HTTP标头。该标头用于控制在网络上缓存文档的方式。该方法有两种重载方式,所不同的是参数。一种重载方法的参数是HttpCacheability枚举值,包括NoCache、Private、Public、Server、ServerAndNoCache和ServerAndPrivate(有关这些枚举值的定义,可参考MSDN)。另一种方法的参数有两个,一个参数是HttpCacheability枚举值,另一个参数是字符串,表示添加到标头的缓存控制扩展。需要注意的是,仅当与Private或NoCache指令一起使用时,字段扩展名才有效。如果组合不兼容的指令和扩展,则此方法将引发无效参数异常。

系统缓存全解析3:页面局部缓存

    有时缓存整个页面是不现实的,因为页的某些部分可能在每次请求时都需要变化。在这些情况下,只能缓存页的一部分。顾名思义,页面部分缓存是将页面部分内容保存在内存中以便响应用户请求,而页面其他部分内容则为动态内容。页面部分缓存的实现包括两种方式:控件缓存和替换后缓存

1. 控件缓存(也称为片段缓存)

    这种方式允许将需要缓存的信息包含在一个用户控件内,然后,将该用户控件标记为可缓存的,以此来缓存页面输出的部分内容。该选项允许缓存页面中的特定内容,而没有缓存整个页面,因此,每次都需重新创建整个页。例如,如果要创建一个显示大量动态内容(如股票信息)的页,其中有些部分为静态内容(如每周总结),这时可以将静态部分放在用户控件中,并允许缓存这些内容

    在ASP.NET中,提供了UserControl这种用户控件的功能。一个页面可以通过多个UserControl来组成。只需要在某个或某几个UserControl里设置缓存

    例如:

    那么可以在WebUserControl1.ascx的页头代码中添加声明语句:

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="WebUserControl1.ascx.cs" Inherits="CacheWebApp._16_4_5.WebUserControl1" %>

<%@ OutputCache Duration="60" VaryByParam="none" %>

<%=DateTime.Now %>

     调用该控件的页面WebForm1.aspx代码:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="CacheWebApp._16_4_5.WebForm1" %>

<%@ Register src="WebUserControl1.ascx" tagname="WebUserControl1" tagprefix="uc1" %>

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>控件缓存</title>

</head>

<body>

<form id="form1" runat="server">

<div>

页面的:<%=DateTime.Now %>

</div>

<div>
控件的:<uc1:WebUserControl1 ID="WebUserControl11" runat="server" />

</div>

</form>

</body>

</html>

这时候刷新WebForm1.aspx页面时,页面的时间每次刷新都变化,而用户控件中的时间数据却是60秒才变化一次,说明对页面的“局部”控件实现了缓存,而整个页面不受影响。

2. 缓存后替换

     与控件缓存正好相反。它对整个页面进行缓存,但是页中的某些片段是动态的,因此不会缓存这些片段。ASP.NET页面中既包含静态内容,又包含基于数据库数据的动态内容。静态内容通常不会发生变化。因此,对静态内容实现数据缓存是非常必要的。然而,那些基于数据的动态内容,则不同。数据库中的数据可能每时每刻都发生变化,因此,如果对动态内容也实现缓存,可能造成数据不能及时更新的问题。对此问题如果使用前文所述的控件缓存方法,显然不切实际,而且实现起来很繁琐,易于发生错误。

     如何实现缓存页面的大部分内容,而不缓存页面中的局部某些片段。ASP.NET 2.0提供了缓存后替换功能。实现该项功能可通过以下三种方法:

    一是以声明方式使用Substitution控件,

    二是以编程方式使用Substitution控件API,

    三是以隐式方式使用控件。

    前两种方法的核心是Substitution控件,本节将重点介绍该控件,第三种方法仅专注于控件内置支持的缓存后替换功能,本节仅做简要说明。

(1) Substitution控件应用

     为提高应用程序性能,可能会缓存整个ASP.NET页面,同时,可能需要根据每个请求来更新页面上特定的部分。例如,可能要缓存页面的很大一部分,需要动态更新该页上与时间或者用户高度相关的信息。在这种情况下,推荐使用Substitution控件。Substitution控件能够指定页面输出缓存中需要以动态内容替换该控件的部分,即允许对整页面进行输出缓存,然后,使用Substitution控件指定页中免于缓存的部分。需要缓存的区域只执行一次,然后从缓存读取,直至该缓存项到期或被清除。动态区域,也就是Substitution控件指定的部分,在每次请求页面时都执行。Substitution控件提供了一种缓存部分页面的简化解决方案。

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm2.aspx.cs" Inherits="CacheWebApp._16_4_5.WebForm2" %>

<%@ OutputCache Duration="60" VaryByParam="none" %>

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>缓存后替换示例</title>

</head>

<body>

<form id="form1" runat="server">

<div>

页面缓存的时间:<%= DateTime.Now.ToString() %>

</div>

<div>

真实(替换)的时间:<asp:Substitution ID="Substitution1" runat="server" MethodName="getCurrentTime" />

</div>

</form>

</body>

</html>

页面后台代码:

public partial class WebForm2 : System.Web.UI.Page

{

public static string getCurrentTime(HttpContext context)

{

return DateTime.Now.ToString();

}

}

    如上代码所示,Substitution控件有一个重要属性:MethodName。该属性用于获取或者设置当Substitution控件执行时为回调而调用的方法名称。该方法比较特殊,必须符合以下3条标准:

Ø 此方法必须被定义为静态方法;

Ø 此方法必须接受HttpContext类型的参数;

Ø 此方法必须返回String类型的值。

     在运行情况下,Substitution控件将自动调用MethodName属性所定义的方法。该方法返回的字符串即为要在页面中的Substitution控件的位置上显示的内容。如果页面设置了缓存全部输出,那么在第一次请求时,该页将运行并缓存其输出。对于后续的请求,将通过缓存来完成,该页上的其他代码不会再运行。但 Substitution控件及其有关方法则在每次请求时都执行,并且自动更新该控件所表示的动态内容,这样就实现了整体缓存,局部变化的替换效果。

     如上代码所示,在代码头部通过@ OutputCache指令设置页面输出缓存过期时间为5秒,这意味着整个页面数据都应用了缓存功能。因此,“页面缓存的时间”所显示的时间值来自于数据缓存。这个时间值不会随着刷新页面而变化,仅当缓存过期时才会发生更新。Substitution控件的MethodName属性值为 getCurrentTime。该控件显示的内容来自于getCurrentTime方法的返回值。尤为重要的是,虽然页面设置了输出缓存功能,但是每当页面刷新时,ASP.NET执行引擎仍然要重新执行Substitution控件,并将MethodName属性值指定的方法返回值显示在页面上,因此,显示的是当前最新时间。

示例效果,如图15-2所示:

图15-2 缓存后替换

随着页面的刷新,真实时间在变,而页面缓存的时间在指定的缓存时间内始终不变。

注意:

l Substitution控件无法访问页上的其他控件,也就是说,无法检查或更改其他控件的值。但是,代码确实可以使用传递给它的参数来访问当前页上下文。

l 在缓存页包含的用户控件中可以包含Substitution控件。但是,在输出缓存用户控件中不能放置Substitution控件。

l Substitution控件不会呈现任何标记,其位置所显示内容完全取决于所定义方法的返回字符串。

(2) Substitution控件API应用

上一小节介绍了以声明方式使用Substitution控件实现缓存后替换的应用。本节说明另一种实现方法。该方法的核心是以编程方式利用Substitution控件API实现缓存后替换,相对于以声明方式使用Substitution控件的方法具有更强灵活性。

通过为Substitution指定回调方法,实现和声明同样的效果。Substitution的回调方法必须是

HttpResponseSubstitutionCallback委托定义的方法,它有两个特征:

l 一是返回值必须是String,

l 二是参数有且仅有一个,并且是HttpContext类型。

当需要以编程方式,为缓存的输出响应动态生成指定的响应区域时,可以在页面代码中将某个方法(即回调方法)的名称作为参数(HttpResponseSubstitutionCallback)传递给Substitution。这样Substitution就能够使用回调方法,并将回调方法的返回值作为给定位置的替代内容显示出来。

需要注意的是,回调方法必须是线程安全的,可以是作为容器的页面或者用户控件中的静态方法,也可以是其他任意对象上的静态方法或实例方法。

下面演示一个以编程方式将 Substitution 控件添加到输出缓存网页。与(1)Substitution控件应用所示的示例完成同样功能。不同的是实现方式。

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm3.aspx.cs" Inherits="CacheWebApp._16_4_5.WebForm3" %>

<%@ OutputCache Duration="60" VaryByParam="none" %>

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>缓存后替换-Substitution控件API应用</title>

</head>

<body>

<form id="form1" runat="server">

<div>

页面缓存的时间:<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>

</div>

<div>

真实(缓存替换)的时间:

<asp:PlaceHolder ID="PlaceHolder1" runat="Server"></asp:PlaceHolder>

</div>

</form>

</body>

</html>

页面后台CS代码:

protected void Page_Load(object sender, EventArgs e)

{

//创建一个Substitution

Substitution Substitution1 = new Substitution();

//指定调用的回调方法名

Substitution1.MethodName = "GetCurrentDateTime";

PlaceHolder1.Controls.Add(Substitution1);

Label1.Text=DateTime.Now.ToString();

}

public static string GetCurrentDateTime(HttpContext context)

{

return DateTime.Now.ToString();

}

    如上代码所示,页面使用@ OutputCache指令设置了输出缓存功能,其配置数据缓存过期时间为60秒。然而,页面其他内容都被缓存,通过Substitution调用的回调方法显示的内容是不被缓存的。

系统缓存全解析4:应用程序数据缓存

    System.Web.Caching 命名空间提供用于缓存服务器上常用数据的类。此命名空间包括 Cache 类,该类是一个字典,您可以在其中存储任意数据对象,如哈希表和数据集。它还为这些对象提供了失效功能,并为您提供了添加和移除这些对象的方法。您还可以添加依赖于其他文件或缓存项的对象,并在从 Cache 对象中移除对象时执行回调以通知应用程序。

/// <summary>

/// 获取当前应用程序指定CacheKey的Cache对象值

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <returns>返回缓存对象</returns>

public static object GetCache(string CacheKey)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

return objCache[CacheKey];

}

/// <summary>

/// 设置当前应用程序指定CacheKey的Cache对象值

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <param name="objObject">缓存对象</param>

public static void SetCache(string CacheKey, object objObject)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

objCache.Insert(CacheKey, objObject);

}

/// <summary>

/// 设置当前应用程序指定CacheKey的Cache对象值

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <param name="objObject">缓存对象</param>

/// <param name="absoluteExpiration">绝对过期时间</param>

/// <param name="slidingExpiration">最后一次访问所插入对象时与该对象过期时之间的时间间隔</param>

public static void SetCache(string CacheKey, object objObject, DateTime absoluteExpiration, TimeSpan slidingExpiration)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

objCache.Insert(CacheKey, objObject, null, absoluteExpiration, slidingExpiration);

}

protected void Page_Load(object sender, EventArgs e)

{

string CacheKey = "cachetest";

object objModel = GetCache(CacheKey);//从缓存中获取

if (objModel == null)//缓存里没有

{

objModel = DateTime.Now;//把当前时间进行缓存

if (objModel != null)

{

int CacheTime = 30;//缓存时间30秒

SetCache(CacheKey, objModel, DateTime.Now.AddSeconds(CacheTime), TimeSpan.Zero);//写入缓存

}

}

Label1.Text = objModel.ToString();

}

    以上几种方法都很好的解决了数据缓存的问题,但由一个最大的问题是当数据发生变化了,而缓存里还是过期的数据,只有等缓存过期后才会重新获取最新的数据,这样的话,很多时候用户获取的数据都是和实际数据不一致的过期数据。这同样给用户造成了比较大的麻烦,怎么办呢?接着往下看。

系统缓存全解析5:文件缓存依赖

    这种策略让缓存依赖于一个指定的文件,通过改变文件的更新日期来清除缓存。

/// <summary>

/// 获取当前应用程序指定CacheKey的Cache对象值

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <returns>返回缓存对象</returns>

public static object GetCache(string CacheKey)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

return objCache[CacheKey];

}

/// <summary>

/// 设置以缓存依赖的方式缓存数据

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <param name="objObject">缓存对象</param>

/// <param name="cacheDepen">依赖对象</param>

public static void SetCache(string CacheKey, object objObject, System.Web.Caching.CacheDependency dep)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

objCache.Insert(

CacheKey, 

objObject,

dep, 

System.Web.Caching.Cache.NoAbsoluteExpiration, //从不过期

System.Web.Caching.Cache.NoSlidingExpiration, //禁用可调过期

System.Web.Caching.CacheItemPriority.Default,

null);

}

protected void Page_Load(object sender, EventArgs e)

{

string CacheKey = "cachetest";

object objModel = GetCache(CacheKey);//从缓存中获取

if (objModel == null) //缓存里没有

{

objModel = DateTime.Now;//把当前时间进行缓存

if (objModel != null)

{

//依赖 C://test.txt 文件的变化来更新缓存

System.Web.Caching.CacheDependency dep = new System.Web.Caching.CacheDependency("C://test.txt");

SetCache(CacheKey, objModel, dep);//写入缓存

}

}

Label1.Text = objModel.ToString();

}

当我们改变test.txt的内容时,缓存会自动更新。这种方式非常适合读取配置文件的缓存处理。如果配置文件不变化,就一直读取缓存的信息,一旦配置发生变化,自动更新同步缓存的数据。

这种方式的缺点是,如果缓存的数据比较多,相关的依赖文件比较松散,对管理这些依赖文件有一定的麻烦。对于负载均衡环境下,还需要同时更新多台Web服务器下的缓存文件,如果多个Web应用中的缓存依赖于同一个共享的文件,可能会省掉这个麻烦。

系统缓存全解析6:数据库缓存依赖

    更多的时候,我们的服务器性能损耗还是在查询数据库的时候,所以对数据库的缓存还是显得特别重要,上面几种方式都可以实现部分数据缓存功能。但问题是我们的数据有时候是在变化的,这样用户可能在缓存期间查询的数据就是老的数据,从而导致数据的不一致。那有没有办法做到,数据如果不变化,用户就一直从缓存中取数据,一旦数据变化,系统能自动更新缓存中的数据,从而让用户得到更好的用户体验。

   答案是肯定的!.NET已经为我们提供了这样一种非常好的解决方法:SqlCacheDependency数据库缓存依赖。

实现步骤:

    下面就让我们看一下如何实现数据库缓存依赖功能:

第一步: 修改web.config,让项目启用SqlCacheDependency 。

将下列代码加入web.config的<system.web>节:

<?xml version="1.0"?>

<configuration>

<appSettings/>

<connectionStrings>

<add name="strcodematic" connectionString="data source=127.0.0.1;initial catalog=codematic;user id=sa;password=" providerName="System.Data.SqlClient" />

</connectionStrings>

<system.web>

<caching>

<sqlCacheDependency enabled="true" pollTime="6000">

<databases>

<add name="codematic" connectionStringName="strcodematic" />

</databases>

</sqlCacheDependency>

</caching>

<compilation debug="true">

</compilation>

<authentication mode="Windows"/>

</system.web>

</configuration>

这里的connectionStringName指定了在<connectionStrings>中添加的某一个连接字符串。name则是为该SqlCacheDependency起的名字,这个名字将在第3步中用到。
SqlCacheDependency类会自动完成对此配置节信息的读取以建立和数据库之间的联系。

注意:

在<databases>节的<add name="codematic" connectionStringName="strcodematic" />中的name属性值必须和第三步的Page_Load代码中System.Web.Caching.SqlCacheDependency("codematic", "P_Product"); 中的第一个参数(数据库名称)相一致。

第二步:执行下述命令,为 数据库启用缓存依赖。

如果要配置SqlCacheDependency,则需要以命令行的方式执行。

aspnet_regsql.exe工具位于Windows//Microsoft.NET//Framework//[版本]文件夹中。

aspnet_regsql -C "data source=127.0.0.1;initial catalog=codematic;user id=sa;password=" -ed -et -t "P_Product"

参数-C后面的字符串是连接字符串(请替换成自己所需要的值),

参数-t后面的字符串是数据表的名字。

运行结果如图15-3所示:

图15-3 启用数据库缓存依赖

 命令执行后,在指定的数据库中会多出一个AspNet_SqlCacheTablesForChangeNotification表

注意:

要使得7.0或者2000版本以上的SQLServer支持SqlCacheDependency特性,需要对数据库服务器执行相关的配置。

有两种方法配置SQLServer:

一 使用aspnet_regsql命令行工具,

二 使用SqlCacheDependencyAdmin类。

例如:

aspnet_regsql -S "server" -E -d "database" –ed 或者

aspnet_regsql -S "server" -E -d "database" -et -t "table"
如果是Sql验证的话要把-E换成,-U (用户名),-P (密码)

以下是该工具的命令参数说明

-? 显示该工具的帮助功能;

-S 后接的参数为数据库服务器的名称或者IP地址;

-U 后接的参数为数据库的登陆用户名;

-P 后接的参数为数据库的登陆密码;

-E 使用当前登录用户的 Windows 集成认证进行身份验证。

-d 后接参数为对哪一个数据库采用SqlCacheDependency功能;

-C 连接数据库的连接字符串。如果您指定服务器(-S)和登录(-U和-P,或 -E)信息,则此选项不是必需的,因为连接字符串已经包含这些信息。

-t 后接参数为对哪一个表采用SqlCacheDependency功能;

-ed 允许对数据库使用SqlCacheDependency功能;

-dd 禁止对数据库采用SqlCacheDependency功能;

-et 允许对数据表采用SqlCacheDependency功能;

-dt 禁止对数据表采用SqlCacheDependency功能;

-lt 列出当前数据库中有哪些表已经采用sqlcachedependency功能。

第三步:在代码中使用缓存,并为其设置SqlCacheDependency依赖:

/// <summary>

/// 获取当前应用程序指定CacheKey的Cache对象值

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <returns>返回缓存对象</returns>

public static object GetCache(string CacheKey)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

return objCache[CacheKey];

}

/// <summary>

/// 设置以缓存依赖的方式缓存数据

/// </summary>

/// <param name="CacheKey">索引键值</param>

/// <param name="objObject">缓存对象</param>

/// <param name="cacheDepen">依赖对象</param>

public static void SetCache(string CacheKey, object objObject, System.Web.Caching.CacheDependency dep)

{

System.Web.Caching.Cache objCache = HttpRuntime.Cache;

objCache.Insert(

CacheKey,

objObject,

dep,

System.Web.Caching.Cache.NoAbsoluteExpiration,//从不过期

System.Web.Caching.Cache.NoSlidingExpiration,//禁用可调过期

System.Web.Caching.CacheItemPriority.Default,

null);

}

protected void Page_Load(object sender, EventArgs e)

{

string CacheKey = "cachetest";

object objModel = GetCache(CacheKey);//从缓存中获取

if (objModel == null)//缓存里没有

{

objModel = GetData();//把当前时间进行缓存

if (objModel != null)

{

//依赖数据库codematic中的P_Product表变化 来更新缓存

System.Web.Caching.SqlCacheDependency dep = new System.Web.Caching.SqlCacheDependency("codematic", "P_Product");

SetCache(CacheKey, objModel, dep);//写入缓存

}

}

GridView1.DataSource = (DataSet)objModel;

GridView1.DataBind();

}

//查询数据

private DataSet GetData()

{

string conString = "data source=127.0.0.1;initial catalog=codematic;user id=sa;password=";

string strSQL = "SELECT * FROM P_Product";

SqlConnection myConnection = new SqlConnection(conString);

DataSet ds = new DataSet();

myConnection.Open();

SqlDataAdapter adapter = new SqlDataAdapter(strSQL, myConnection);

adapter.Fill(ds, "Product");

myConnection.Close();

return ds;

}

     从以上代码可以看出,和文件依赖基本相同,只是在存放缓存SetCache时存入的依赖对象不同罢了。这里用的是SqlCacheDependency。

     其中,创建SqlCacheDependency的构造方法:

public SqlCacheDependency (string databaseEntryName,string tableName)

l databaseEntryName :是在Web.config 文件的 caching 节的 sqlCacheDependency 的 databases 元素中定义的数据库的名称。

l tableName :与 SqlCacheDependency 关联的数据库表的名称。

    这样,只有当P_Product表的内容发生变化时,查询操作才会重新查询数据更新缓存的内容,可以大大减少数据库的重复查询和提高系统的性能和运行效率。

系统缓存全解析7:第三方分布式缓存解决方案 Memcached和Cacheman

Memcached — 分布式缓存系统

1.Memcached是什么?

    Memcached是高性能的,分布式的内存对象缓存系统,用于在动态应用中减少数据库负载,提升访问速度。Memcached通过在内存里维护一个统一的巨大的hash表,它能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等。Memcached由Danga Interactive最初为了加速 LiveJournal网站访问速度而开发的,后来被很多大型的网站采用。起初作者编写它可能是为了提高动态网页应用,为了减轻数据库检索的压力,来做的这个缓存系统。它的缓存是一种分布式的,也就是可以允许不同主机上的多个用户同时访问这个缓存系统,这种方法不仅解决了共享内存只能是单机的弊端,同时也解决了数据库检索的压力,最大的优点是提高了访问获取数据的速度!基于memcached作者对分布式cache的理解和解决方案。memcached完全可以用到其他地方比如分布式数据库,分布式计算等领域。Memcached将数据库负载大幅度降低,更好的分配资源,更快速访问。

2.Memcached工作机制

    通过在内存中开辟一块区域来维持一个大的hash表来加快页面访问速度,和数据库是独立的。但是目前主要用来缓存数据库的数据。允许多个server通过网络形成一个大的hash,用户不必关心数据存放在哪,只调用相关接口就可。存放在内存的数据通过LRU算法进行淘汰出内存。同时可以通过删除和设置失效时间来淘汰存放在内存的数据。

    现在一些.NET开发人员开始放弃ASP.NET内置的缓存机制,转而使用Memcached——一种分布式的内存缓存系统。当运行在单独的Web服务器上,你可以很容易地清除一个已经确认被改变了的缓存。可惜,ASP.NET没有一个很好的方法来支持多服务器。每个服务器上的缓存都对其他缓存的改变一无所知。

    ASP.NET允许通过基于文件系统和数据库表的触发器来作废一个缓存。然而,这也存在问题,比如数据库触发器需要使用昂贵的轮询,以及触发器本身冗长的编程。但是,我们还是有其他的选择的。

    不像ASP.NET内置的缓存机制,Memcached是一个分布式的缓存系统。任何Web服务器都能更新或删除一个缓存项,并且所有其他的服务器都能在下次访问这些缓存项的时候自动获取到更新的内容。这是通过把这些缓存项存储在一个或者多个缓存服务器上来实现的。每一个缓存项都根据它的关键字的哈希值来分配到一个服务器上。

    表面看来,Memcached针对ASP.NET的API就像和内置的API一样。这让开发人员很容易地转换到Memcached上,仅仅通过在代码中查找和替换即可实现。

    一个被推荐的解决方案是不根据缓存项的关键字来生成哈希键值。这将允许开发人员能够让一个给定页面中需要的所有缓存项,尽量存放在同一个服务器上。可惜,基于数据保存的地方而不是基于缓存项自身的关键字来生成哈希键,很容易产生错误,需要仔细来实现(这个算法)。

     Memcached是基于Linux运行的,你可以在BSD的许可协议下使用Memcached。他也提供了针对C#的客户端以及Perl、Python、PHP、Java和其他语言的API:http://www.danga.com/memcached/apis.bml。还有一个Win32的移植版本(http://jehiah.cz/projects/memcached-win32/),可以让Memcached运行在非Linux的机器上。

Cacheman — .NET架构下的分布式缓存项目

      Cacheman据说是由微软旗下的 Popfly 项目组成员 Sriram Krishnan 的作品。是他用业余时间开发的。最新的情况是,微软的 Popfly 网站已经“悄悄地”的做了更新,就是采用了 Krishnan 的 Cacheman,更新了缓存机制。该项缓存技术更新带来的性能提升非常显著,根据Popfly团队中的 John Montgomery 的说法:加载一个已有的Mashup应用时,可以带来2到6倍的性能提升。

       这些说法也得到了 Krishnan 本人的确认。他提到这是Cacheman 的第一次的实际应用,并自豪的说 Cacheman 不费吹灰之力就拿下了 Popfly 的全部访问量。

     简单介绍一下 Cacheman 这个项目。资料主要来源于 Krishnan的博客对Cacheman的介绍。

Cacheman是一个基于Windows平台的快速分布式哈希表。是由纯托管代码实现。中间搁置了有几个月,直到最近才开始重新上马这个项目,极可能就是因为Popfly项目需要的缘故才开始着手的。

     Krishnan本人对 memcached 很感兴趣,于是创建了 Cacheman。Cacheman上有很多 memcached 的影子,比如与memcached相似的文本通讯协议。Cacheman的通讯协议公开,任何人可以根据自己偏爱的语言环境写客户端。 Krishnan 在自己家用电脑(2.4GHz Intel Core 2 带2GB内存)上进入测试,达到了每秒16000次左右的请求,并且还是服务器与客户端都是在同一台服务器下完成的。

    现这款产品还不太完善,作者自身也提到:在Cacheman做指定key的GET/SET/DELETE操作时,客户端需要弄清需要与哪一台 Cacheman服务器通讯,为此要对该key做一个快速FNV哈希然后求余得到应该和几台服务器中的哪台服务器通讯。但该法的缺点在于新增或删除一个服务器节点时,缓存节点需要大规模迁移。修复该问题需要一致性的哈希算法,作者表示还没有时间解决此事。作者提出了采用中心架构的“主缓存服务器”的解决办法,让客户端轮询主缓存服务器来获取应该与那个缓存服务器通讯,但他也觉的这样做增加了复杂性,会带来些新问题。

    可以感觉到,由于 Cacheman 这个个人项目已经介入到 Popfly 这个正式产品中,可能很快就会被微软吸纳为正式产品,因此如果有人采用这个产品做自己缓存的解决方案的话,应该不必太担心后续的产品升级及文档支持服务,它的未来前途值的期待。说不定 Krishnan 会从 Popfly 项目脱身出来专职负责这个 Cacheman 项目。

目前最新的版本是0.0.2版 :http://www.sriramkrishnan.com/code/

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 扫一扫,分享海报

参与评论 您还未登录,请先 登录 后发表或查看评论
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值