2010年的大型网站，面临的题目已经不再是内容的集中广播式展示的题目了，而是越来越多的用户交互式应用及以由于 这些应用产生的海量个性化数据。好比以用户为中央大型电子商务网站、SNS社会化网络、SocialGame以及其他新兴的Web2.0模式的大型网站及 应用。所以这里只讨论高度交互性海量数据的大型网站，而不讨论新闻类和一些依赖HTML静态化就可以实现的Web1.0时代的网站架构。好比国内，开心网 等类似的web2.0系列架构。我们这里也不讨论站点是PHP、J2EE、 仍是ROR、Python 等基础运行环境。无论采用什么语言或基础运行环境，架构都是我们所必需要面临的。

1、海量数据的处理 众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面临的题目，本身负载量不是很大，最多再加几个索引就 可以搞定。对于大型网站，天天的数据量可能就上百万，假如一个设计不好的多对多关系，在前期是没有任何题目的，但是跟着用户的增长，数据量会是几何级的增 长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的本钱的非常高的。

2、数据并发的处理 在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大题目。在整个应用程序下，缓存是全局共享的，然而在我们进 行修改的时候就，假如两个或者多个哀求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。 另外，就是数据库的死锁题目，也许平时我们感觉不到，死锁在高并发的情况下的泛起的概率长短常高的，磁盘缓存就是一个大题目。

3、文件存贮的题目 对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照 日期和类型进行存贮。但是当文件量是海量的数据的情况下，假如一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的 题目，哪怕你的带宽足够，但是你的磁盘也未必响应过来。假如这个时候还涉及上传，磁盘很轻易就over了。 也许用raid和专用存贮服务器能解决眼下的题目，但是还有个题目就是各地的访问题目，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决? 假如做分布式，那么我们的文件索引以及架构该如何规划。 所以我们不得不承认，文件存贮是个很不轻易的题目

4、数据关系的处理 我们可以很轻易的规划出一个符合第三范式的数据库，里面充满了多对多关系，还能用GUID来替代INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必需有效的把多表联合查询降到最低。

5、数据索引的题目 众所周知，索引是进步数据库效率查询的最方面最廉价最轻易实现的方案。但是，在高UPDATE的情况下，update和delete付出的本钱会高的无法 想想，笔者碰到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。 索引和更新是一对生成的冤家，我们在做架构的时候不得不考虑这点，并且也可能是花费时间最多。

6、分布式处理 对于2.0网站因为其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面临一个绝大的题目，就是如何有效的实现数据同步和更新，实现各地服务器的实时通信有是一个不得不需要考虑的题目。

7、Ajax的利弊分析 成也AJAX，败也AJAX，AJAX成为了主流趋势，溘然发现基于XMLHTTP的post和get是如斯的轻易。客户端get或者post 到服务器数据，服务器接到数据哀求之后返归来，这是一个很正常的AJAX哀求。但是在AJAX处理的时候，假如我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX哀求的话，我们可以构造一个发包机，很轻易就可以把一个webserver干掉。

8、数据安全性的分析 对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G题目来说的话，加密的过程就可能是明文了(好比我们知道的 QQ，可以很轻易的判定他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后， 那么所谓的外挂，所谓的群发就会相继而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判定甚至HTTPS来实现，注 意，当你做这些处理的时候付出的将是海量的database，io以及CPU的本钱。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和 qq空间的群发了。大家愿意尝尝，实际上并不是很难。