大型网站架构系列之一.docx

大型网站架构系列之一.docx

《大型网站架构系列之一.docx》由会员分享，可在线阅读，更多相关《大型网站架构系列之一.docx（14页珍藏版）》请在冰豆网上搜索。

大型网站架构系列之一

大型网站架构系列之一不得不考虑的问题

前言：

这两天机器坏了，正在送修中，写个系列的大型网站架构的文章，希望对有志在互联网做出一番事业的站长朋友们一些帮助。

　　注意：

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。

我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。

　　文入正题：

　　首先讨论一下大型网站需要注意和考虑的问题

　　A.海量数据的处理。

　　众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。

对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。

在这个时候我们对于一个表的select和update的时候（还不说多表联合查询）的成本的非常高的。

　　B.数据并发的处理

　　在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。

对于缓存，在高并发高处理的时候也是个大问题。

在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。

这个时候，就需要一个好的数据并发处理策略以及缓存策略。

　　另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

　　C.文件存贮的问题

　　对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。

常见的方案是对文件按照日期和类型进行存贮。

但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。

如果这个时候还涉及上传，磁盘很容易就over了。

　　也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?

如果做分布式，那么我们的文件索引以及架构该如何规划。

　　所以我们不得不承认，文件存贮是个很不容易的问题

　　D.数据关系的处理

　　我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFYCOLUMN但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。

必须有效的把多表联合查询降到最低。

　　E.数据索引的问题

　　众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。

但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。

　　索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，

　　F.分布式处理

　　对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。

为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

　　G.Ajax的利弊分析

　　成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。

客户端get或者post到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。

但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。

对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。

　　H.数据安全性的分析

　　对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了（比如我们知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的）。

当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来（从qq一开始的群发可见端倪）。

也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。

对于一些群发，基本上是不可能的。

笔者已经可以实现对于XX空间和qq空间的群发了。

大家愿意试试，实际上并不是很难。

　　I.数据同步和集群的处理的问题

　　当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。

而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。

比如数据散列，分割，内容处理等等问题

　　K.数据共享的渠道以及OPENAPI趋势

　　Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。

这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

　　当然还有更多需要考虑的问题，我这里就写一个最需要考虑的问题，欢迎补充。

下一篇文章将针对问题A，提出具体的解决方案和思路

大型网站架构系列之二底层架构概论

首先澄清上篇中关于几个朋友的评论。

　　上篇介绍的基于AJAX的攻击很多人提出疑问，比如不能跨域，减轻负担之类。

Ajax是通过简单的GET和POST进行数据传递的，采用HTTPDEBUGGER，抓取数据，然后采用如下方案，顺便写个示例的攻击代码.比传统的webform，我们更容易构造一些，其实对于webform和ajax的处理和发包过程是一样的，ajax数据量相对小，速度也快一些。

　　结合SharpPcap和HttpWebRequest我们构造一个合理的正常的IP数据包过去,代码很长，我们用伪代码简单的表达一下。

　　request.CreateUrl（Ajax处理页面）;

　　request.Method=”GetORPost”;

　　request.refere=”网页来源”;

　　SharpPcap.SetLinkConnection（伪造IP地址）;

　　Stringcontent=request.GetResponseStream（）如果作为一个多线程的应用程序对对方的WEB构成批量发包的话（假如是DEDECMS），足可以把Dedecms的数据库搞垮

　　文入正题：

　　对于上回书提到要解决问题A，我们先讲解一下电信公司ADSL的布局方案。

机器上没有装VISIO，我简单的用文字描述一下流程。

　　Adsl用户Aè输入用户名密码è远程连接到账户数据库（在天津）è账户数据库连接计费数据库并返回状è如果成功，连接PPPOE服务器，并进一步连接计费数据库è认证服务并连接。

　　这里没有什么特别的地方，但是和qq通讯服务是一样的，就是采用了统一的用户验证服务器，同时对于用户验证的信息数据库是只读的，我们从其中可以想到什么吗?

　　以上是个简单的例子，下面开始谈具体的架构策略，首先对于上篇提到的问题A，我们首先以用户数据库为例来做解释和要求。

　　首先做用户量估算需求，假如我们做的是学术社区，那么这个用户量不会很大，可能我们不需要考虑这个，对于用户量的级别，我们暂时把用户量级别定为三种，百万级别（M）和千万界别（S），以及亿万级别（Q），并考虑用户登录验证以及查询常用的操作，对M和S进行扩充以及了解。

　　众所周知，在这个情况下，对于用户数据的负载其实并非可行而不可行的问题，而是如何最大化的保证查询和更新以及各个服务器之间的数据同步。

这里我们不再讲解如何优化如何索引，只介绍架构初期的方案，下面介绍的方案如果涉及全表查询，可以采用分区视图的方案，大家可以具体搜索相关资料。

　　对于M级别来说，现有的DBMS经过合理的布局完全可以满足需求。

我们需要解决的问题的关键其实是处理IO方面的问题，处理方案相对简单一些，对数据库的FILE文件分磁盘存贮（不是分区，是不同的硬盘），根据负载量大小，我们可以适当的控制硬盘的数量和文件分区的数量。

　　对于S级别，上个处理方案已经不能完全满足需求了，这个时候我们需要对注册和入库的流程进行简单的修改了，解决方案是数据散列和分区视图的概念，具体概念大家去google一下，我不详细说明了。

　　我们常用的方案有三种。

第一种是等容扩充法，在用户注册控制的基础上，保证每个库的用户容量不超过500万，超过之后入第二个库，以此类推，这个方案可以保证系统有效的扩充性，但不能保证数据被有效的索引。

第二种就是共区索引方案，其实和第一种方案有异曲同工的之说但是讲第一种方案进行了合理的优化，按照用户名进行分库存贮。

比如我们可以建立26的数据库，按照用户名的索引来控制用户数据入哪个库。

假如用户名是CrazyCoder，那么就讲该用户名的数据存放在用户表C中，在数据存贮的时候可以很方便的根据用户名进行相应的数据查询，方案二可以有效的解决数据索引问题。

方案三是一个更具模型化的方案，结合方案一和方案二，进行用户ID的编码，不是INDENTIFYCloumn，我们用一种序列化的方案将用户名以编码的形式存贮，比如用户名是CrazyCoder,我们的编码方案就是通过算法进行数字化，将CrazyCoder按照C，R,A,….存贮为数字索引，然后进行分区存贮，数字类型的数据在数据库中可以更有效的被查询和被更新和共享，结合方案一和方案二这个就是方案三。

　　对于Q级别。

数据量已经是足够海量了，这个时候无论用哪种方案都是一个让人头大的数据，不能简单的用查询的方案来处理了，可以参考S级别的进行处理。

但这个时候我们采用的方案是根据用户活跃度的权值结合数据量进行临时数据表的存放。

如果一个非意外的数据情况下，每天登录的用户量不会上千万。

这个时候我们需要做的是一个简单的数据代理程序。

一个临时的用户验证数据库，每天执行一次批处理，将活跃度高的用户账户提取到临时数据库中，查询的时候先查询临时库，如果没有在进行全库查询。

这个根据系统的负载情况来估计阈值，不同的系统估算方案也不尽相同。

　　上面对于，M,S,Q三种界别进行了简单的概述，下面介绍一个在其之上更高级的一个查询方案，数据缓存服务器，我们也可以把它理解为缓冲服务器，数据做为只读来使用。

　　具体实现方案如下：

以为涉及了海量，DBMS常规的缓存方案已经不符合我们的要求了，那么我们需要一个有效的缓存方案，这个时候处理的流程其实就是讲最常用最直接的数据直接存放在缓存服务器中，而这个缓存服务器定时从主服务器获取并更新信息。

这个是一个简单的查询，我们还可以更深入的讲缓存服务器做二次缓存，也就是一次性处理输入并存放到LIST数据中，作为全局变量放到内存中进行查询，同时用HASHTABLE或者数组进行数据