写这篇文章之前，需要有些论点和论据，以表明网络系统在极端情况下的情况，先来看看世界上排名靠前的网站。
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/2=5000/2=2500/2=1250/2=625/2=314/2=157/2=78/2=39/2=19/2=9/2=4/2=2/2=1，计算结果后，一共是计算了14次。就拿本次测试CPU的可以接受结果1亿来计算。
100000000/14=7142857
相当于1万台服务器，每台每秒分配可以并发7142857的DNS返回值。
从单台电脑的并发来看，如果每秒可以解析转发700多万次。这样每分钟42000万，每小时2520000万次，就拿一天24小时，可能网站的高峰期为8小时吧，因为很多人都是在醒着的时候访问网站，2520000*8=20160000万次，也就是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索引的性能了。
上文说过一般使用磁盘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+树数据结构
=============================================================================================================
1）B树
B树中每个节点包含了键值和键值对于的数据对象存放地址指针，所以成功搜索一个对象可以不用到达树的叶节点。
成功搜索包括节点内搜索和沿某一路径的搜索，成功搜索时间取决于关键码所在的层次以及节点内关键码的数量。
在B树中查找给定关键字的方法是：首先把根结点取来，在根结点所包含的关键字K1,…,kj查找给定的关键字（可用顺序查找或二分查找法），若找到等于给定值的关键字，则查找成功；否则，一定可以确定要查的关键字在某个Ki或Ki+1之间，于是取Pi所指的下一层索引节点块继续查找，直到找到，或指针Pi为空时查找失败。
2）B+树
B+树非叶节点中存放的关键码并不指示数据对象的地址指针，非也节点只是索引部分。所有的叶节点在同一层上，包含了全部关键码和相应数据对象的存放地址指针，且叶节点按关键码从小到大顺序链接。如果实际数据对象按加入的顺序存储而不是按关键码次数存储的话，叶节点的索引必须是稠密索引，若实际数据存储按关键码次序存放的话，叶节点索引时稀疏索引。
B+树有2个头指针，一个是树的根节点，一个是最小关键码的叶节点。
所以 B+树有两种搜索方法：
一种是按叶节点自己拉起的链表顺序搜索。
一种是从根节点开始搜索，和B树类似，不过如果非叶节点的关键码等于给定值，搜索并不停止，而是继续沿右指针，一直查到叶节点上的关键码。所以无论搜索是否成功，都将走完树的所有层。
B+ 树中，数据对象的插入和删除仅在叶节点上进行。这两种处理索引的数据结构的不同之处：
a，B树中同一键值不会出现多次，并且它有可能出现在叶结点，也有可能出现在非叶结点中。而B+树的键一定会出现在叶结点中，并且有可能在非叶结点中也有可能重复出现，以维持B+树的平衡。
b，因为B树键位置不定，且在整个树结构中只出现一次，虽然可以节省存储空间，但使得在插入、删除操作复杂度明显增加。B+树相比来说是一种较好的折中。
c，B树的查询效率与键在树中的位置有关，最大时间复杂度与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等办公后台类型系统，能涉及到医药，社保，*等等诸多系统。
这类系统要求可能会要求比较复杂，首先是要求查询速度，其次是要求更新的要及时。就是说，要更新马上出结果，查询马上能找到刚刚更新的内容。前段入口有几种方式。
一、可以采用缓存形式DNS+CDN，缓存的类似前台框架，比如extjs，或者jquery的框架内容，登录后，利用js级别的程序，去确定连接哪台web服务器，因为这种无刷新框架采用的几乎都是数据传输模式，这就有点像写Winform+Winserver（CS模式），只不过其中的Client是用JS写的，服务器也是JS去选择的。
二、可以才用二级域名绑定，或者干脆使用IP，当客户在页面登陆后，自动跳转到对应的系统。
这类系统，一定是各个分部，乃至各个部门都有自己的服务和分系统，这种架构思想其实就是把所有业务一样的系统，利用一个查询库联系起来，各个分系统实时上传最新的消息，以备其他系统
访问操作流程：
客户通过一个总入口，进入到分系统，每个分系统服务器就在一部门内部，比如：*系统，在某个*或派出所。当然，这种松散耦合就直接可以考增加分系统解决，比如某派出所系统达到饱和，可以在增加一套分系统，比如*二号网。
而整体联网的重担就肩负在上传信息的服务器上了。数据库有个矛盾点，数据加了索引，查询速度快，而增删改的速度就慢。而数据少的数据库，查询速度也很快，利用这个特点，分系统在进行增删改的同时，向工作数据库提交一份备份信息，在有另一台服务器实时的把数据拷贝到历史数据库并生成索引，当查询的时候，同时从两台服务器共同返回结果。当有删和改的数据时，要在工作数据库中进行标注，改的数据，以工作库为准，删的数据即使从历史索引数据库里提出来，也不进行显示。在查询中，势必要有分页算发，当两张表进行并的时候，所以就要在查询时候，功能上有所区别。分上下两个表显示。在查单条信息时，合并两个表选出内容即可。