企业网络营销推广方法研究,网站做优化必须要ftp吗,网页ui设计图,哈尔滨市香坊区建设局网站写这篇文章之前#xff0c;需要有些论点和论据#xff0c;以表明网络系统在极端情况下的情况#xff0c;先来看看世界上排名靠前的网站。
1、 FaceBook 2、 Google 从这两个站可以看出#xff0c;当下比较极限的日均访问量在2~3亿#xff0c;PV值…写这篇文章之前需要有些论点和论据以表明网络系统在极端情况下的情况先来看看世界上排名靠前的网站。
1、 FaceBook 2、 Google 从这两个站可以看出当下比较极限的日均访问量在2~3亿PV值达到4~5亿
就算是很庞大的系统了。 下面要用通俗一点的话讲一下这个互联网的访问过程。 从上面的过程中文明知道Whois我们是无法左右的我们的可以着手负载的地方就是DNS级别开始。域名解析到DNS具体和什么IP进行交互可以由DNS动态绑定分配。
首先我们要测定一个理论值测试一下单机极端能力情况下的结果。
测试机器配置 测试代码
private void button1_Click(object sender, EventArgs e) { //1000万台服务器折半查找10次 string ees ; long dtst DateTime.Now.Ticks; for (int i 0; i 100000000; i) { ees 211.112.111.212; } string dted TimeSpan.FromTicks(DateTime.Now.Ticks - dtst).ToString(); MessageBox.Show(dted); } 测试结论
本次测试采用的是笔记本上网本电脑凌动(Atom)处理器1.6Ghz的主频。循环赋值了一亿次时间大概为1秒左右。现在的服务器的至强CPU运算速度能力至少在Atom的运算速度的10倍以上。从DNS解析中中间可能要涉及到IP地址的路径查找就算一台DNS解析器带一万台服务器一万台服务器IP地址进行排序后折半查找路径查找路径的计算过程为10000/25000/22500/21250/2625/2314/2157/278/239/219/29/24/22/21计算结果后一共是计算了14次。就拿本次测试CPU的可以接受结果1亿来计算。
100000000/147142857
相当于1万台服务器每台每秒分配可以并发7142857的DNS返回值。 从单台电脑的并发来看如果每秒可以解析转发700多万次。这样每分钟42000万每小时2520000万次就拿一天24小时可能网站的高峰期为8小时吧因为很多人都是在醒着的时候访问网站2520000*820160000万次也就是20160亿次。这个数据比较现在极端情况下的网站来讲日均访问量的PV最多也不超过5亿。更何况现在采用测试配置是那么的低一般服务器CPU都要比这速度高十倍以上。当然本次测试并没有考虑到带宽线路等问题但是理论结果想证明的是从DNS开始进来解决负载问题是可行的结果。基本不用考虑是否会对DNS服务器造成多大的压力。
架构原理
现今面临的Web有几种
1. CMS内容管理系统,就是类似一些门户网站发些新闻资讯等内容。
2. B2B B2C商城系统里面有商品有购物车还有账户还有针对商品的分类以及查询。
3. 论坛/博客/微博系统就是每一个用户都有发信息读信息的权限功能。
4. 搜索引擎就是利用蜘蛛程序把网站信息爬到系统内部然后分析整理出关键字以关键字作为索引对内容进行整理。
5. OA/CRM/MIS等办公后台类型系统能涉及到医药社保公安等等诸多系统。
面临问题
一般网站面临的问题就是负载的问题当人数多导致速度慢是主要解决的问题。 而其实最主要原因就是瓶颈问题现在很多网站都是一个DNS绑定一个网站IP的A记录然后为了达到功能上的负载可能会利用二级域名绑定N个IP然后相互利用入口进行从功能上的切割达到负载目的。而第二个瓶颈点就是数据库无论用什么样的数据库服务器单机作战一定有它的最大负荷如并发连接过大数据过多就容易导致数据返回慢从而导致前台web服务器应用的速度慢。
技术原理
数据库有些问题首先就是当数据大了多了的时候面临的问题就是查询速度。学过数据结构的人都则数据库的查询速度增加可以利用折半查找方式而折半查找就需要一个排序好的文件数据。这就是数据库中所谓的索引。而带索引字段的表有一个弊因为每次要排序的字段都要重新寻找位置所以在插入修改删除数据的时候一定会更新一下索引表导致增删改的操作速度会慢数据越大它越慢。
下面做一个测试
测试一返回数据
条件一
未加索引
数据库总共数据200多万 条件二
Type加索引
数据库总共数据200多万 从以上的测试可以对比 未加索引 加了索引 Top:1% Scan Table: 99% Top:6% Scan Table: 94% 3秒 2秒 测试二模糊查询: 未加索引 带索引 数据库索引是数据库管理系统中一个排序的数据结构以协助快速查询、更新数据库表中数据。索引的实现通常使用B树及其变种B树。
在数据之外数据库系统还维护着满足特定查找算法的数据结构这些数据结构以某种方式引用指向数据这样就可以在这些数据结构上实现高级查找算法。这种数据结构就是索引。
为表设置索引要付出代价的一是增加了数据库的存储空间二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。 上图展示了一种可能的索引方式。左边是数据表一共有两列七条记录最左边的是数据记录的物理地址注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的。为了加快Col2的查找可以维护一个右边所示的二叉查找树每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针这样就可以运用二叉查找在O(log2n)的复杂度内获取到相应数据。 创建索引可以大大提高系统的性能。
第一通过创建唯一性索引可以保证数据库表中每一行数据的唯一性。
第二可以大大加快数据的检索速度这也是创建索引的最主要的原因。
第三可以加速表和表之间的连接特别是在实现数据的参考完整性方面特别有意义。
第四在使用分组和排序子句进行数据检索时同样可以显著减少查询中分组和排序的时间。
第五通过使用索引可以在查询的过程中使用优化隐藏器提高系统的性能。 也许会有人要问增加索引有如此多的优点为什么不对表中的每一个列创建一个索引呢因为增加索引也有许多不利的方面。
第一创建索引和维护索引要耗费时间这种时间随着数据量的增加而增加。
第二索引需要占物理空间除了数据表占数据空间之外每一个索引还要占一定的物理空间如果要建立聚簇索引那么需要的空间就会更大。
第三当对表中的数据进行增加、删除和修改的时候索引也要动态的维护这样就降低了数据的维护速度。 索引是建立在数据库表中的某些列的上面。在创建索引的时候应该考虑在哪些列上可以创建索引在哪些列上不能创建索引。一般来说应该在这些列上创建索引在经常需要搜索的列上可以加快搜索的速度在作为主键的列上强制该列的唯一性和组织表中数据的排列结构在经常用在连接的列上这些列主要是一些外键可以加快连接的速度在经常需要根据范围进行搜索的列上创建索引因为索引已经排序其指定的范围是连续的在经常需要排序的列上创建索引因为索引已经排序这样查询可以利用索引的排序加快排序查询时间在经常使用在WHERE子句中的列上面创建索引加快条件的判断速度。 同样对于有些列不应该创建索引。一般来说不应该创建索引的的这些列具有下列特点
第一对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为既然这些列很少使用到因此有索引或者无索引并不能提高查询速度。相反由于增加了索引反而降低了系统的维护速度和增大了空间需求。
第二对于那些只有很少数据值的列也不应该增加索引。这是因为由于这些列的取值很少例如人事表的性别列在查询的结果中结果集的数据行占了表中数据行的很大比例即需要在表中搜索的数据行的比例很大。增加索引并不能明显加快检索速度。
第三对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为这些列的数据量要么相当大要么取值很少。
第四当修改性能远远大于检索性能时不应该创建索引。这是因为修改性能和检索性能是互相矛盾的。当增加索引时会提高检索性能但是会降低修改性能。当减少索引时会提高修改性能降低检索性能。因此当修改性能远远大于检索性能时不应该创建索引。 根据数据库的功能可以在数据库设计器中创建三种索引唯一索引、主键索引和聚集索引。
唯一索引
唯一索引是不允许其中任何两行具有相同索引值的索引。
当现有数据中存在重复的键值时大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如如果在employee表中职员的姓(lname)上创建了唯一索引则任何两个员工都不能同姓。
主键索引
数据库表经常有一列或列组合其值唯一标识表中的每一行。该列称为表的主键。
在数据库关系图中为表定义主键将自动创建主键索引主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时它还允许对数据的快速访问。
聚集索引
在聚集索引中表中行的物理顺序与键值的逻辑索引顺序相同。一个表只能包含一个聚集索引。
如果某索引不是聚集索引则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比聚集索引通常提供更快的数据访问速度。 局部性原理与磁盘预读
由于存储介质的特性磁盘本身存取就比主存慢很多再加上机械运动耗费磁盘的存取速度往往是主存的几百分分之一因此为了提高效率要尽量减少磁盘I/O。为了达到这个目的磁盘往往不是严格按需读取而是每次都会预读即使只需要一个字节磁盘也会从这个位置开始顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理当一个数据被用到时其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。
由于磁盘顺序读取的效率很高不需要寻道时间只需很少的旋转时间因此对于具有局部性的程序来说预读可以提高I/O效率。
预读的长度一般为页page的整倍数。页是计算机管理存储器的逻辑块硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块每个存储块称为一页在许多操作系统中页得大小通常为4k主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时会触发一个缺页异常此时系统会向磁盘发出读盘信号磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中然后异常返回程序继续运行。
B-/Tree索引的性能分析
到这里终于可以分析B-/Tree索引的性能了。
上文说过一般使用磁盘I/O次数评价索引结构的优劣。先从B-Tree分析根据B-Tree的定义可知检索一次最多需要访问h个节点。数据库系统的设计者巧妙利用了磁盘预读原理将一个节点的大小设为等于一个页这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的在实际实现B-Tree还需要使用如下技巧
每次新建节点时直接申请一个页的空间这样就保证一个节点物理上也存储在一个页里加之计算机存储分配都是按页对齐的就实现了一个node只需一次I/O。
B-Tree中一次检索最多需要h-1次I/O根节点常驻内存渐进复杂度为O(h)O(logdN)。一般实际应用中出度d是非常大的数字通常超过100因此h非常小通常不超过3。
而红黑树这种结构h明显要深的多。由于逻辑上很近的节点父子物理上可能很远无法利用局部性所以红黑树的I/O渐进复杂度也为O(h)效率明显比B-Tree差很多。 综上所述用B-Tree作为索引结构效率是非常高的。 应该花时间学习B-树和B树数据结构 1B树
B树中每个节点包含了键值和键值对于的数据对象存放地址指针所以成功搜索一个对象可以不用到达树的叶节点。
成功搜索包括节点内搜索和沿某一路径的搜索成功搜索时间取决于关键码所在的层次以及节点内关键码的数量。
在B树中查找给定关键字的方法是首先把根结点取来在根结点所包含的关键字K1,…,kj查找给定的关键字可用顺序查找或二分查找法若找到等于给定值的关键字则查找成功否则一定可以确定要查的关键字在某个Ki或Ki1之间于是取Pi所指的下一层索引节点块继续查找直到找到或指针Pi为空时查找失败。
2B树
B树非叶节点中存放的关键码并不指示数据对象的地址指针非也节点只是索引部分。所有的叶节点在同一层上包含了全部关键码和相应数据对象的存放地址指针且叶节点按关键码从小到大顺序链接。如果实际数据对象按加入的顺序存储而不是按关键码次数存储的话叶节点的索引必须是稠密索引若实际数据存储按关键码次序存放的话叶节点索引时稀疏索引。
B树有2个头指针一个是树的根节点一个是最小关键码的叶节点。
所以 B树有两种搜索方法
一种是按叶节点自己拉起的链表顺序搜索。
一种是从根节点开始搜索和B树类似不过如果非叶节点的关键码等于给定值搜索并不停止而是继续沿右指针一直查到叶节点上的关键码。所以无论搜索是否成功都将走完树的所有层。
B 树中数据对象的插入和删除仅在叶节点上进行。这两种处理索引的数据结构的不同之处 aB树中同一键值不会出现多次并且它有可能出现在叶结点也有可能出现在非叶结点中。而B树的键一定会出现在叶结点中并且有可能在非叶结点中也有可能重复出现以维持B树的平衡。 b因为B树键位置不定且在整个树结构中只出现一次虽然可以节省存储空间但使得在插入、删除操作复杂度明显增加。B树相比来说是一种较好的折中。 cB树的查询效率与键在树中的位置有关最大时间复杂度与B树相同(在叶结点的时候)最小时间复杂度为1(在根结点的时候)。而B树的时候复杂度对某建成的树是固定的。
架构设计
由于数据库的单台负载能力问题所以数据量到一定规模无论什么数据库都有一定的瓶颈在里面。所以分布式数据库是需要考虑的。就像Google那么大的数据量根本就不可能单台服务器能解决也不是哪一个服务器机房的集群能解决的Google利用GFS分布式存储一样。
1、 CMS内容管理系统,就是类似一些门户网站发些新闻资讯等内容。
挡在前面的就应该是静态页面的缓存这需要每次刷一次新内容要把数据库动态内容进行生成静态页面可以利用CDN服务器进行内容分发负载。也可以部署分布式文件服务器利用DNS动态解析来进行负载。因为网络上有很多服务器节点被分发到同样的数据内容。这样客户访问会找到最近得节点进行连接从而达到负载目的。 访问操作流程
客户访问
客户首先通过DNS服务器找到最近的CDN节点。从节点读出缓存的静态内容当客户想进行数据的查询的时候才调用Web服务器的程序内容数据库服务器里的表结构都是一样的由于数据库可能会成为瓶颈所以Web服务器会去一个使用率并不高的数据库节点进行查询。因为Web服务器也是个集群系统在缓存内容的时候就自动分配一个Web服务器写到CDN所缓存的内容里。这样就可以灵活调配 (缓存-Web-数据库) 的数量当访问量达到一定量系统变慢可以合理分析出原因高松散耦合性的增加服务器。
后台操作
内容分发管理应该有一个专门的后台系统访问数据库其中的任何一个固定的数据库然后连接当进行增删改操作的时候这台服务器立刻进行响应结果然后把对应的SQL语句发送到消息队列同步其他数据库的相关内容。同时通知缓存整理服务器访问这台固定的数据库进行缓存内容整理上传到CDN。
以上图例负载如果是都在内网也可以采用类似F5,LVS那种负载分发机配合缓存服务器进行解决。
系统特点适用于更新相对不是特别频繁的企业站门户网站新闻类分类信息等等网站。
2、 B2B B2C商城系统里面有商品有购物车还有账户还有针对商品的分类以及查询
这种网站类型里面涉及到交易交易就涉及到事务如果是单台服务器数据库可以用事务进行解决但是单台数据库服务器到一定规模远远的达不到性能负载要求。而且系统要解决有几方面的问题对于新发布的商品要有查看和查询面临着客户的访问量也是需要考虑高负载并发的同时又要兼顾买卖交易问题。这一点淘宝做的就很好。他的原理就是相当于有若干个小的商城网站系统然后利用淘宝平台把所有小的商城网站联系在一起。 访问操作流程
客户注册后在把信息录入到某个小商城网站的同时留在用户索引数据库一份索引值来记录这个用户属于哪个小商城网站的。在登录的时候通过用户索引数据库就把对应的客户Session状态固定在当初注册的小商品网站上。小商品网站数据库采用双机热备形式里面有店商的产品资料客户资料客户的购物车资料以及当天的交易记录资料。交易记录每天要把其交易信息填入到历史交易数据库中并按着日期进行添加索引。这样保证工作表数据一直都是少的操作起来就会很快。店商把产品信息发布的同时也推送到CMS系统一份CMS系统进行内容分类整理缓存索引等。当客户登录后首先通过CMS系统整体搜索自己想要的关键字以及分类信息搜素到后点击就进入提供商品信息小商城网站服务器下浏览。添加购物车的时候是把对方的商品编号记录在自己注册的小商城服务器下。最后是交易。由于有可能注册的服务器和提供商品的服务器不是同一服务器所以要借助中间交易服务器进行清算。就像支付宝一样一方面客户服务器预付款同时交易服务器向商品提供电商发送指令预减去商品数量然后交易服务器最后汇总并向两台服务器同时保证交易的事务性。当然在交易过程中商品数量被其他交易影响减为零的时候预付款也会进行回滚把钱还给客户。 异常处理
在客户端向商品服务器提送预减商品的同时自己的交易状态表就要挂起同一时间只能有一个交易状态一个交易状态结束后才可以进行下一个交易如果客户在交易途中出现如网络断线等问题时候异常进行等待。等恢复后客户端向交易服务器请求询问商品服务器是否状态交易成功成功后自己把欠款扣下恢复到非交易状态如果未成功就把欠款恢复到交易以前。当然在断线后商品服务器有可能接手不到交易服务器的确认信息可以在1分钟后超时恢复状态。
系统特点系统有很多瓶颈当发现小商城网站不够用或饱和的时候可以无限增加小商品网站和数据库服务器也可以按着地域和注册时候的IP选择就近可以操作服务器进行注册和操作。搜索商品信息可以利用上面的CMS系统框架可以承受很大的负载同时保证两者的高松散耦合性。
3、论坛/博客/微博系统就是每一个用户都有发信息读信息的权限功能。
和商城系统的理念差不多前端为了解决用户并发访问的问题还是要用CMS来解决问题。同时为了解决客户操作庞大问题也是要用户索引表索引到每一台Web服务器上。不过这种发文章性质的系统在发布到CMS系统之前要根据相关法律规定要对内容有审核也许是人工审核也许是系统关键字审核。 访问和操作流程
注册的时候根据网络情况系统固定分配一台论坛Web服务器比如论坛web服务器1。客户登录后就进入论坛Web服务器1系统客户在系统上进行写文章发文章发出的文章同时提交到内容审核数据库审核成功后就发送到CMS系统上。然后其他可以通过CMS系统可以查找到你的对应文章。
4、搜索引擎就是利用蜘蛛程序把网站信息爬到系统内部然后分析整理出关键字以关键字作为索引对内容进行整理。
顾名思义搜索引擎的数据内容都是利用蜘蛛程序在网络上爬下来的然后进行针对用户搜索的关键字汉字常用词组等进行索引连接制作。比如客户搜索 “大连 北京 机票”搜索引擎会同时对这三个关键字的索引进行展开搜索。其次就是对服务器的内容进行整理建立索引的过程。 访问操作流程
客户通过DNS寻找到CDN节点后输入关键字内容然后服务器逻辑把关键字内容用 空格或其他符号进行拆分出几个关键字。然后到关键字索引数据库中进行查询返回的结果排序自然是根据SEO规则进行详细情况请搜索“SEO”同时如果发现关键字数据库里没有的就把新的关键字记录到关键字数据库。返回的结果集可以通过连接连接到当初抓取数据的数据库同时也可以利用快照地址读取分布式文件系统里抓取的快照内容查看。
蜘蛛服务器程序每天实时的在互联网上获取新的快照网页信息。加工关键字符服务器拥有中国汉字里常见的词组和词句并联合客户本身输入的关键字数据库在蜘蛛抓到的快照内容中不断的比对并制作关键字索引到索引服务器上。为了解决负载问题同时去更新多个关键字索引数据库以便前台Web服务器分布式连接。
5、OA/CRM/MIS等办公后台类型系统能涉及到医药社保公安等等诸多系统。
这类系统要求可能会要求比较复杂首先是要求查询速度其次是要求更新的要及时。就是说要更新马上出结果查询马上能找到刚刚更新的内容。前段入口有几种方式。
一、可以采用缓存形式DNSCDN缓存的类似前台框架比如extjs或者jquery的框架内容登录后利用js级别的程序去确定连接哪台web服务器因为这种无刷新框架采用的几乎都是数据传输模式这就有点像写WinformWinserverCS模式只不过其中的Client是用JS写的服务器也是JS去选择的。
二、可以才用二级域名绑定或者干脆使用IP当客户在页面登陆后自动跳转到对应的系统。
这类系统一定是各个分部乃至各个部门都有自己的服务和分系统这种架构思想其实就是把所有业务一样的系统利用一个查询库联系起来各个分系统实时上传最新的消息以备其他系统 访问操作流程
客户通过一个总入口进入到分系统每个分系统服务器就在一部门内部比如公安系统在某个分局或派出所。当然这种松散耦合就直接可以考增加分系统解决比如某派出所系统达到饱和可以在增加一套分系统比如分局二号网。
而整体联网的重担就肩负在上传信息的服务器上了。数据库有个矛盾点数据加了索引查询速度快而增删改的速度就慢。而数据少的数据库查询速度也很快利用这个特点分系统在进行增删改的同时向工作数据库提交一份备份信息在有另一台服务器实时的把数据拷贝到历史数据库并生成索引当查询的时候同时从两台服务器共同返回结果。当有删和改的数据时要在工作数据库中进行标注改的数据以工作库为准删的数据即使从历史索引数据库里提出来也不进行显示。在查询中势必要有分页算发当两张表进行并的时候所以就要在查询时候功能上有所区别。分上下两个表显示。在查单条信息时合并两个表选出内容即可。
