疯狂代码,大型网站架构系列(全)

《疯狂代码,大型网站架构系列(全)》由会员分享，可在线阅读，更多相关《疯狂代码,大型网站架构系列(全)（12页珍藏版）》请在金锄头文库上搜索。

1、疯狂代码疯狂代码,大型网站架构系列之一大型网站架构系列之一,前言前言,不得不考虑的问题不得不考虑的问题前言：这两天机器坏了，正在送修中，写个系列的大型网站架构的文章，希望对有志在互 联网做出一番事业的站长朋友们一些帮助。注意：这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周 知的原因，我们就不谈新闻类和一些依靠 HTML 静态化就可以实现的架构了，我们以高负 载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的 web2.0 系列架构。我 们这里不讨论是 PHP 还是 JSP 或者.NET 环境，我们从架构的方面去看问题，实现语言方 面并不是问题，语言的优势在于

2、实现而不是好坏，不论你选择任何语言，架构都是必须要 面对的。文入正题： 首先讨论一下大型网站需要注意和考虑的问题 A. 海量数据的处理。 众所周知，对于一些相对小的站点来说，数据量并不是很大，select 和 update 就可以解决 我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站， 每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的， 但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的 select 和 update 的时候(还不说多表联合查询)的成本的非常高的。 B. 数据并发的处理 在一些时候，2.0 的 C

3、TO 都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候 也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就， 如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个 时候，就需要一个好的数据并发处理策略以及缓存策略。 另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的 概率是非常高的，磁盘缓存就是一个大问题。 C. 文件存贮的问题 对于一些支持文件上传的 2.0 的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考 虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行 存贮。但是当文

4、件量 是海量的数据的情况下，如果一块硬盘存贮了 500 个 G 的琐碎文件， 那么维护的时候和使用的时候磁盘的 Io 就是一个巨大的问题，哪怕你的带宽足够，但是你 的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就 over 了。 也许用 raid 和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题， 也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决？如果做分布式，那 么我们的文件索引以及架构该如何规划。 所以我们不得不承认，文件存贮是个很不容易的问题 D. 数据关系的处理 我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用 GUI

5、D 来替换 INDENTIFY COLUMN 但是，多对多关系充斥的 2.0 时代，第三范式是第一 个应该被抛弃的。必须有效的把多表联合查询降到最低。 E. 数据索引的问题 众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE 的情况下，update 和 delete 付出的成本会高的无法想想，笔者遇到过一个情况， 在更新一个聚焦索引的时候需要 10 分钟来完成，那么对于站点来说，这些基本上是不可忍 受的。 索引和更新是一对天生的冤家，问题 A，D，E 这些是我们在做架构的时候不得不考虑的 问题，并且也可能是花费时间最多的问题， F. 分布式处理 对于 2.

6、0 网站由于其高互动性，CDN 实现的效果基本上为 0，内容是实时更新的，我们常 规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的 实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。 G. Ajax 的利弊分析 成也 AJAX，败也 AJAX，AJAX 成为了主流趋势，突然发现基于 XMLHTTP 的 post 和 get 是如此的容易。客户端 get 或者 post 到服务器数据，服务器接到数据请求之后返回来，这 是一个很正常的 AJAX 请求。但是在 AJAX 处理的时候，如果我们使用一个抓包工具的话， 对数据返回和处理是一目了然。对于

7、一些计算量大的 AJAX 请求的话，我们可以构造一个 发包机，很容易就可以把一个 webserver 干掉。 H. 数据安全性的分析 对于 HTTP 协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是 对于 G 问题来说的话，加密的过程就可能是明文了（比如我们知道的 QQ，可以很容易的 判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的） 。当你站点流量不是很 大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接 踵而来（从 qq 一开始的群发可见端倪） 。也许我们可以很的意的说，我们可以采用更高级 别的判断甚至 HTTPS 来实现，注意，当

8、你做这些处理的时候付出的将是海量的 database，io 以及 CPU 的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对 于百度空间和 qq 空间的群发了。大家愿意试试，实际上并不是很难。 I. 数据同步和集群的处理的问题 当我们的一台 databaseserver 不堪重负的时候，这个时候我们就需要做基于数据库的负载和 集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计 的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另 外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散 列，分割，内容处理等等问

9、题 K数据共享的渠道以及 OPENAPI 趋势Openapi 已经成为一个不可避免的趋势，从 google，facebook，myspace 到海内校内，都 在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助 你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的 途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考 的问题了。当然还有更多需要考虑的问题，我这里就写一个最需要考虑的问题，欢迎补充。下一篇文章将针对问题 A，提出具体的解决方案和思路待续（ 和 同步发布，转载请注明出处）疯狂代码疯狂代码,大型网站架构系

10、列之二，底层架构概论大型网站架构系列之二，底层架构概论书结上回， 上篇疯狂代码介绍的基于 AJAX 的攻击很多人提出疑问，比如不能跨域，减轻负担之类。 Ajax 是通过简单的 GET 和 POST 进行数据传递的，采用 HTTPDEBUGGER，抓取数据， 然后采用如下方案，顺便写个示例的攻击代码比传统的 webform，我们更容易构造一些， 其实对于 webform 和 ajax 的处理和发包过程是一样的，ajax 数据量相对小，速度也快一些。结合 SharpPcap 和 HttpWebRequest 我们构造一个合理的正常的 IP 数据包过去,代码很长， 我们用伪代码简单的表达一下。 re

11、quest.CreateUrl(Ajax 处理页面); request.Method=”GetORPost”;request.refere=”网页来源”; SharpPcap.SetLinkConnection(伪造 IP 地址); String content = request.GetResponseStream() 如果作为一个多线程的应用程序对对方的 WEB 构成批量发包的话（假如是 DEDECMS） ，足可以把 Dedecms 的数据库搞垮文入正题： 对于上回书提到要解决问题 A，我们先讲解一下电信公司 ADSL 的布局方案。机器上没有 装 VISIO，我简单的用文字描述一下流程。

12、Adsl 用户 A 输入用户名密码 远程连接到账户数据库（在天津） 账户数据库连接计费 数据库并返回状 如果成功，连接 PPPOE 服务器，并进一步连接计费数据库 认证服务并 连接。这里没有什么特别的地方，但是和 qq 通讯服务是一样的，就是采用了统一的用户验证服务 器，同时对于用户验证的信息数据库是只读的，我们从其中可以想到什么吗？以上是个简单的例子，下面开始谈具体的架构策略，首先对于上篇提到的问题 A，我们首 先以用户数据库为例来做解释和要求。 首先做用户量估算需求，假如我们做的是学术社区，那么这个用户量不会很大，可能我们 不需要考虑这个，对于用户量的级别，我们暂时把用户量级别定为三种，百

13、万级别（M） 和千万界别（S） ，以及亿万级别（Q） ，并考虑用户登录验证以及查询常用的操作，对 M 和 S 进行扩充以及了解。众所周知，在这个情况下，对于用户数据的负载其实并非可行而不可行的问题，而是如何 最大化的保证查询和更新以及各个服务器之间的数据同步。这里我们不再讲解如何优化如 何索引，只介绍架构初期的方案，下面介绍的方案如果涉及全表查询，可以采用分区视图 的方案，大家可以具体搜索相关资料。对于 M 级别来说，现有的 DBMS 经过合理的布局完全可以满足需求。我们需要解决的问 题的关键其实是处理 IO 方面的问题，处理方案相对简单一些，对数据库的 FILE 文件分磁 盘存贮（不是分区，

14、是不同的硬盘） ，根据负载量大小，我们可以适当的控制硬盘的数量和 文件分区的数量。对于 S 级别，上个处理方案已经不能完全满足需求了，这个时候我们需要对注册和入库的 流程进行简单的修改了，解决方案是数据散列和分区视图的概念，具体概念大家去 google 一下，我不详细说明了。 我们常用的方案有三种。第一种是等容扩充法，在用户注册控制的基础上，保证每个库的 用户容量不超过 500 万，超过之后入第二个库，以此类推，这个方案可以保证系统有效的 扩充性，但不能保证数据被有效的索引。第二种就是共区索引方案，其实和第一种方案有 异曲同工的之说但是讲第一种方案进行了合理的优化，按照用户名进行分库存贮。比如

15、我 们可以建立 26 的数据库，按照用户名的索引来控制用户数据入哪个库。假如用户名是 CrazyCoder，那么就讲该用户名的数据存放在用户表 C 中，在数据存贮的时候可以很方便 的根据用户名进行相应的数据查询，方案二可以有效的解决数据索引问题。方案三是一个 更具模型化的方案，结合方案一和方案二，进行用户 ID 的编码，不是 INDENTIFY Cloumn，我们用一种序列化的方案将用户名以编码的形式存贮，比如用户名是 CrazyCoder,我 们的编码方案就是通过算法进行数字化，将 CrazyCoder 按照 C，R,A,.存贮为数字索引， 然后进行分区存贮，数字类型的数据在数据库中可以更有

16、效的被查询和被更新和共享，结 合方案一和方案二这个就是方案三。对于 Q 级别。数据量已经是足够海量了，这个时候无论用哪种方案都是一个让人头大的数 据，不能简单的用查询的方案来处理了，可以参考 S 级别的进行处理。但这个时候我们采 用的方案是根据用户活跃度的权值结合数据量进行临时数据表的存放。如果一个非意外的 数据情况下，每天登录的用户量不会上千万。这个时候我们需要做的是一个简单的数据代 理程序。一个临时的用户验证数据库，每天执行一次批处理，将活跃度高的用户账户提取 到临时数据库中，查询的时候先查询临时库，如果没有在进行全库查询。这个根据系统的 负载情况来估计阈值，不同的系统估算方案也不尽相同。上面对于，M,S,Q 三种界别进行了简单的概述，下面介绍一个在其之上更高级的一个查询 方案，数据缓存