|
互动性高的系统轻易碰到的问题是数据库高并发。数据库的许多操作是有锁的，锁保留在体系表里，假如系统的吞吐量也满意不了需要，那么锁就会呈现问题了。你能够以为，数据库一次至多只能有100个衔接（在SQL2005服务器版本上测试）。如果超越了，那么，第101个就会超时。如果有一条语句操作时光很长，也操作频繁，那么应当很容易就引起数据库超时的过错。 现在，本文还有一个问题没解决呢，那是第一部门遗留的。要增添服务器，那怎么安排呢？ 对数据拜访慢的情况，需要对数据库进行优化。包含优化查询语句，优化数据库构造，索引优化。而对于单表数据好多少千万条的优化则需要进行分表。在SQL2005以前版本中并没有，不使用内置的表分区功效，需要本人实现。策略普通是依照时间，把数据放到不同的表中。然后再使用视图功能把表查询聚合到一起。这种方法和SQL2005带的表分区比拟有很大不同，效力远比SQL2005带的要低。为什么呢？好比SQL2000，树立两张雷同结构的表，贮存数据。表一跟表二都是500万数据。查询时，先从表1筛选到数据，再从表二筛选到数据，然后合并，再按前提排序，还是单线程的，这能不慢吗?而SQL2005是可以把索引放到不同的分区，多线程地去操作，因为是在过程内实现数据的筛选排序，速度还是很快。当然，条件是服务器有很多个核。（SQL2005表分区只在服务器版中可以应用。） 对于第一种供给内容的网站而言，会出现两种情况。一种是数据容量过大，因为早期设计失误，造成数据库访问速度很慢；第二种是访问人数过多，造成IIS响应不外来，反应在访问速度慢或者罗唆报Service Unavailable毛病。或者两种情况都产生了。 荣幸的是，在处置的语句中有良多是反复的。比方，当初拦阻器如图2.1一样工作，在1秒钟内，拦截了101条命令，归并出有20条语句都是查问的同样的内容（个别是列表页），最后收拾出实际须要操作40条命令，而后履行命令，拿到数据库后散发给这101个恳求。也就是说101个工作被紧缩成了40个工作。 二、互动性高的系统 -->这种系统，如果数据库自身已经知足不了了，可以用拦截器来解决。用拦截器也需要斟酌怎么设计计划。假设现在每秒钟有100条数据库操作命令，而这100条命令各不相同，并且数据库1秒钟恰好能处理这100条命令。那现在每秒钟有101条命令，并且命令还是各不相同，每秒中与每秒钟发生的命令也是不相同的，那么做拦截器也是毫无用途的。最多只能有一个缓解作用。由于每秒钟都会增长一条无奈处理的命令。 对于IIS响应慢或者Service Unavailable的情况，有可能是带宽太小，也可能是连接数太多了。我记得有人做过测试，IIS的TCP连接数最大大略是8000的样子，Unix下的Apache(还是httpd忘却了。)最大连接数一万多。似乎说是操作系统TCP/IP堆栈的限度，我对这方面不太懂。如果超过这个量或者是其它相似的起因造成了web服务不稳固，那么就该加服务器了。 而涌现大表的情形，仍是参考本文的第一局部解决。 图2.1
一、提供内容为主的系统 对于SQL查询的优化，缓存也能帮到必定的忙。比如，有个结合查询，查询的是文章分类表和文章表。完整可以只查文章表，而文章表中只有分类ID，显示的时候怎么办？在内存中，缓存了一个分类字典，键就是分类ID,值就是分类名称。显示的时候，直接用文章内分类ID在字典中找。这样就进步了SQL语句的效率。 当然缓存块也可以加在Web利用的部分。重要用来保存一段时间内不更新的数据，当然，这个缓存是有过时策略的。 话接前文《网-站、数据-库的衍变之路(二)》。上文讲了几种静态化方案的利弊，有朋友要讲具体一点，呵呵，这不属于本文的范围。也有友人说有些网站不合适搞静态化，是有这种情况。然而在这个时代，网站还处于刚发展的起始阶段。初期的网站用户量往往很小，都是以提供征询为主，典范的web1.0系统，静态化方案是和这个背景严密相干的。而跟着网站的逐渐发展又会遇到些什么样的问题呢？这个要看网站发展的实际情况。大体上分为两类：一、就是做资讯的，用户正常是从搜寻引擎过来的，没有多少的交互义务；二、以做SNS或者论坛这类互动性高的产品的（用论坛提供下载或者文字浏览的不在此例）。 还可以对某些不常变动的数据进行缓存。比如文章的分类，用户的名字（这个要看注册用户增加的情况）。图2.1的模型改成图2.2的情况。 相关的主题文章： (责任编辑：admin) |