数据库压力解决方法及网站大流量压力应对.doc

数据库压力解决方法 目前言兑网访问量，越来越大了，言兑网全部是动态页，需要数据及时响应给客户，目前CPU占用率已经在10%-80%中浮动，如果不设置缓存，那么直接会导致大家访问不了本站或者响应速度很慢。为了以后做准备，特地收集了一下数据库压力解决资料，为以后做准备，基于目前的状况我们的目标是用最少的资金获取最大的性能效益。数据库服务器负载均衡集群的实现：MS SQL Server数据库服务器可以说是应用范围最广的数据库产品，并且越来越多地在大型和比较关键的应用系统中提供服务。当企业应用越来越复杂、数据量越来越大的时候，SQL Server数据库要不停的进行处理、存储、查询的工作，这个时候企业就要考虑SQL Server数据库服务器的性能和速度及安全性了。 SQL Server 2005仍然不直接地支持负载均衡但是它为以前SQL Server版本中可用的所有负载均衡方法提供了令人激动的改善和支持。 目录1、端到端拓扑的事务性复制2、表分割3、备份和重新存储上的改善(片段式重新存储)4、数据库镜像和快照端到端拓扑的事务性复制SQL Server 2005对端到端(P2P)的拓扑结构上的事务性的复制加强了支持。SQL Server 2000支持双向的复制，这就可以让两台服务器同时对彼此发布和订阅数据。服务器可以更新同一个共享数据，但是在这样的拓扑中你被限制在两台服务器上。P2P的拓扑结构支持无限的发布服务器，他们彼此之间可以互相交换事务。当然，当参加的发布者的数量增加之后，事务性的延迟也就更大了。虽然在你的P2P拓扑结构中对节点的数量没有理论上的限制，但是只有在某个确定的数字之下才可以提供可接受的性能。微软推荐低于12个节点，以保证性能的优化。无论怎样，P2P拓扑都是SQL Server的一个巨大进步：现在，多端点服务器可以更改数据，并且向其他的发布者复制事务。这就是说，订阅服务器不再被限制在主要的报告环境中。你可以通过事务性负载全球共享的方式将服务器分布开来。当用户的数量增加的时候，只要简单地向这个群体中添加服务器即可。除了将负载分布之外，这个拓扑结构还增加了可用性。如果任何一个点的服务器不可达，则池中其它的服务器就会共享这个负载，因为每个服务器都有其它所有服务器上可获得的全部数据集合。以下的表列出了使用P2P拓扑结构来进行负载均衡的优点和缺点。优点:所有参与的服务器都有完全的数据集合。 用户可以连接到任何一个点的服务器上来读取或者修改数据。由于负载在服务器之间进行了均衡，读取的性能得到了很大程度的改善。 缺点:多个服务器会修改同一个数据，这会导致冲突。事务性复制不支持具有超出常规的冲突解决方案。你必须找出解决或者防止潜在冲突的解决方法。 当端点服务器的数量增加的时候，性能会大幅下降。写活动重复，因为所有的数据都在同一台服务器上。 注意：复制在处理数据库计划无缝修改方面也进行了加强。在以前的发布中，修改复制的对象的计划需要关机时间。但是在SQL Server 2005中就不是这样的情况了。表分割分布式分区视图的工作方式在SQL Server 2005中与以前版本中的工作方式相同。然而，SQL Server 2005还支持表分区，这可以让你通过分布读写负载到多个磁盘(或者磁盘阵列)上来改善性能。对于分区表，你必须识别分区要用的是哪一个卷，还有每个分区的范围。例如，一个标识字段的数值可以定义分区范围;一个分区内可以允许从1到1百万的数值，在第二个分区内可以允许1百万到2百万，以此类推。分区范围可以通过分区函数来指定.然后你还必须创建一个分区计划来讲分区函数中定义的每个范围值映射到分离的文件组上去。每个文件组都可以放在不同的磁盘上。以下的表给出了表分区的优缺点：表分区的优缺点优点使用分区计划和函数很容易建立 简化了对大表的维护(有几十亿行记录) 允许为每个分区创建独立的索引缺点 分区字段支持的数据类型有一定限制 必须为每个单独的分区建立一个表都，但是你可以在多个表上重复使用同一个分区函数。表分区可以让你将负载扩展到磁盘上去。然而，所有的数据都必须被同一个服务器管理。如果你的性能瓶颈与CPU或者内存有关，那么这种方法看起来不是你最好的选择。 备份和重新存储方面的改善(片段式重新存储)SQL Server的备份和重新存储特性没有很大的改变，但是微软确实添加了一些新的函数来允许用户比以前更快地访问被重新存储的数据库。SQL Server 2005现在支持片段式数据库重新存储。片段式重新存储可以让你首先重新存储主要的文件组，然后将数据库启动，处于在线状态。然后，可用的第二个文件组也可以被重新存储。只要第一文件组被重新存储了，那么用户就可以连接到数据库了。其他的文件组可以继续重新存储，与此同时，数据库也可以为查询和事务提供服务。正在重新存储的文件组标记为离线。假设你有一个100GB的数据库，其中的75GB是历史性数据，很少被访问到。你可以将这些历史性数据放在它自己的文件组里面，然后让那些频繁访问的数据放在另外一个文件组。如果你将最近的数据放在第一文件组中，那么你就只需要重新存储25GB的数据就可以让用户连接到你的数据库上。然后你再重新存储其它的保留历史性数据的文件组。以下的表列出了这个备份和重新存储解决方案的优缺点：备份和重新存储的优缺点：优点实现和维护非常简单 允许对报告数据库进行读取和写入缺点 不能提供最新的数据 在重新存储的时候，数据库不能访问。这就意味着报告无法生成。 数据库镜像和快照SQL Server 2005引入了数据库镜像的概念来帮助获得高可用性。特别提醒的是，只要它正是发布了，数据库镜像就可以在SQL Server 2005上使用。然而，只有到SQL Server 2005 Service Pack 1才会支持镜像，暂定在2006年年初发布。从本质上来说，镜像的工作方式与日志传输类似。1、事务日志记录可以应用在两个服务器中的数据库文件上。与日志传输不同的是，数据库镜像不需要你备份事务日志，也不需要拷贝备份到备份服务器上。2、数据库镜像连续两次写入数据。与日志传输不同，备份的数据库必须保持在非恢复的模式中，这可以防止对数据的访问，即使是只读的方式。然而，镜像允许对备份数据库进行快照。数据库快照是SQL Server 2005中引入的另一项特性。快照是某一个时间点上的数据库的克隆。只要你的镜像的数据库进行了快照，你就可以让用户查询快照。快照的生成通常只需要几秒钟，因为它实际上在这个过程中拷贝任何数据。因此，要把负载分布到你的主服务器和备用服务器上，你可以将你的数据库镜像，然后阶段性地对备份服务器进行快照。你还可以使用快照在主服务器上进行报告。以下的表列出了数据库镜像和快照的优缺点：数据库镜像和快照的优缺点优点从镜像数据库中生成快照非常快 数据是最新的，因为它是持续写入镜像 在同一个数据库上可以生成多个快照缺点: 快照提供了对数据的只读访问. 拥有快照，会增加服务器的负担，对性能产生负面影响 如果你正好对镜像服务器进行错误恢复，那么事务和报告活动都会指向同一个服务器（但是不同的数据库）。然而，长期以来，SQL SERVER数据库服务器都只有“热备”的解决方案，而没有“负载均衡”和“集群”的解决方案。这种解决方案固然提升了系统的可靠性，但也存在一些问题：面对大数据量和大量的数据库查询请求，只能采取纵向提升服务器档次的方法，而纵向提升的成本远远高于横向扩展。 在热备时，数据库服务器只有一台在工作，另一台处于闲置备份的状态，造成了投资的浪费。 非实时切换。而数据库路由器软件ICX的出现，为基于MS SQL Server的数据库系统提供了一种更优秀的集群解决方案。它可以真正的实现SQL Server数据库服务器的动态负载均衡，提高性能和速度；它可以真正的保证SQL Server数据库服务器不间断的提供服务，在服务器发生故障的时候实时切换到其他服务器上继续提供服务，切换时间为“零”。数据库路由器是实时并发数据库事务处理同步复制器和负载平衡器。数据库路由器-ICX（意思是：I SEE X DATABASE SERVERS），也就是说，在ICX后面可以同时连接N个数据库，结构如下图所示：1所有的数据库客户都通过ICX访问数据库。当访问、查询SQL Server数据库的时候ICX可以根据实际情况分配服务器来提供服务，大大提高服务速度和优化性能，完成负载均衡。2ICX可以同时连接多台数据库（2-16台，具体连多少台，看客户的具体需求而定），这若干台数据库的内容在任何时刻由ICX保证是完全一致的。也就是说，ICX采用了全新的并发事务处理的方式，向连接的N台数据库同步复制事务处理，使得系统在任何时刻具有多个一致的最新逻辑数据库数据集。当其中一台数据库服务器发生故障的时候，ICX可以实时的、第一时间切换到其他服务器上来继续提供服务。真正的实现零时间的服务器切换，大大提高安全性，真正意义的实现服务器不间断服网站大流量压力 如何进行系统应对？ 当一个企业的网站访问量越来越大时，当一个博客发展为知名博客的时候，博客的访问量通常都会非常大，使用使用虚拟主机的话，个人博客由于访问量过大经常会而引起url=/服务器/url性能问题，这是很多人的烦恼，有人使用取消url=/searchwhatis/251/6093751.shtmlRSS/url等错误的方法来解决问题，显然是下错药，那么对于网站大流量带来的问题，正确的解决方法应该是什么呢?下面是我个人总结的一些经验，供大家参考。第一步：确认服务器硬件能力普通的url=/searchwhatis/383/6025883.shtmlP4/url服务器一般最多能支持每天10万独立url=/searchwhatis/191/6025691.shtmlIP/url，如果访问量比这个还要大，那么必须首先配置一台更高性能的专用服务器才能解决问题，否则怎么优化都不可能彻底解决性能问题。第二步：优化url=/数据库/url访问服务器的负载过大，一个重要的原因是url=/searchwhatis/461/5947461.shtmlCPU/url负荷过大，降低服务器CPU的负荷，才能够有效打破url=/searchwhatis/146/7475146.shtml瓶颈/url。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。缓存技术就是另一个解决方案，就是将动态数据url=/存储/url到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-url=/searchwhatis/366/5946866.shtmlBlog/url都大量使用这种缓存技术。我自己也写过一个Z-Blog的计数器插件，也是基于这样的原理。如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询SQL.避免使用Select * from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大量SQL查询。第三，禁止外部的盗链。外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，url=/searchwhatis/299/6025299.shtmlApache/url自己就可以通过配置来禁止盗链，url=/searchwhatis/452/6025452.shtmlIIS/url也有一些第三方的url=/searchwhatis/229/6025729.shtmlISAPI/url可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。第四，控制大文件的下载。大文件的下载会占用很大的流量，并且对于非url=/searchwhatis/427/5948927.shtmlSCSI/url硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。目前有不少免费的url=/searchwhatis/445/7372445.shtmlWeb 2.0/url网站提供图片分享和文件分享功能，因此可以尽量将图片和文件上传到这些分享网站。第五，使用不同主机分流主要流量将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主