大型网站架构方案分析与总结.doc

大型网站架构不得不考虑的10个问题大型网站架构只包括高互动性高交互性的数据型大型网站基于大家众所周知的原因我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了我们以高负载高数据交换高数据流动性的网站为例比如海内开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境我们从架构的方面去看问题实现语言方面并不是问题语言的优势在于实现而不是好坏不论你选择任何语言架构都是必须要面对的。这里讨论一下大型网站需要注意和考虑的问题。1、海量数据的处理众所周知对于一些相对小的站点来说数据量并不是很大select和update就可以解决我们面对的问题本身负载量不是很大最多再加几个索引就可以搞定。对于大型网站每天的数据量可能就上百万如果一个设计不好的多对多关系在前期是没有任何问题的但是随着用户的增长数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。2、数据并发的处理在一些时候2.0的CTO都有个尚方宝剑就是缓存。对于缓存在高并发高处理的时候也是个大问题。在整个应用程序下缓存是全局共享的然而在我们进行修改的时候就如果两个或者多个请求同时对缓存有更新的要求的情况下应用程序会直接的死掉。这个时候就需要一个好的数据并发处理策略以及缓存策略。另外就是数据库的死锁问题也许平时我们感觉不到死锁在高并发的情况下的出现的概率是非常高的磁盘缓存就是一个大问题。3、文件存贮的问题对于一些支持文件上传的2.0的站点在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下如果一块硬盘存贮了500个G的琐碎文件那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题哪怕你的带宽足够但是你的磁盘也未必响应过来。如果这个时候还涉及上传磁盘很容易就over了。也许用raid和专用存贮服务器能解决眼下的问题但是还有个问题就是各地的访问问题也许我们的服务器在北京可能在云南或者新疆的访问速度如何解决?如果做分布式那么我们的文件索引以及架构该如何规划。所以我们不得不承认文件存贮是个很不容易的问题4、数据关系的处理我们可以很容易的规划出一个符合第三范式的数据库里面布满了多对多关系还能用GUID来替换INDENTIFYCOLUMN但是多对多关系充斥的2.0时代第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。5、数据索引的问题众所周知索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是在高UPDATE的情况下update和delete付出的成本会高的无法想想笔者遇到过一个情况在更新一个聚焦索引的时候需要10分钟来完成那么对于站点来说这些基本上是不可忍受的。索引和更新是一对天生的冤家问题ADE这些是我们在做架构的时候不得不考虑的问题并且也可能是花费时间最多的问题。6、分布式处理对于2.0网站由于其高互动性CDN实现的效果基本上为0内容是实时更新的我们常规的处理。为了保证各地的访问速度我们就需要面对一个绝大的问题就是如何有效的实现数据同步和更新实现各地服务器的实时通讯有是一个不得不需要考虑的问题。7、Ajax的利弊分析成也AJAX败也AJAXAJAX成为了主流趋势突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post到服务器数据服务器接到数据请求之后返回来这是一个很正常的AJAX请求。但是在AJAX处理的时候如果我们使用一个抓包工具的话对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话我们可以构造一个发包机很容易就可以把一个webserver干掉。8、数据安全性的分析对于HTTP协议来说数据包都是明文传输的也许我们可以说我们可以用加密啊但是对于G问题来说的话加密的过程就可能是明文了(比如我们知道的QQ可以很容易的判断他的加密并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你但是当你流量上来之后那么所谓的外挂所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说我们可以采用更高级别的判断甚至HTTPS来实现注意当你做这些处理的时候付出的将是海量的databaseio以及CPU的成本。对于一些群发基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家愿意试试实际上并不是很难。9、数据同步和集群的处理的问题当我们的一台databaseserver不堪重负的时候这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了数据基于网络传输根据数