大型网站架构必须要面对的问题

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

1、海量数据的处理
众所周知，对于普通的小型网站来说，数据量并不算大，单一数据库表的读和写就可以解决数据访问的所有问题了。由于本身负载量不是很大，最多再加几个索引，在性能上就可以 简单的起到优化作用了。但是，对于大型网站来说，每天的数据量可能就上百万，如果一个或者多个设计不好的多对多关系，是会存在巨大问题的。在网站上线的早期 ，用户量少的时候，复杂的应用看起来可能没有任何问题，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候 的成本的非常昂贵的，更不用说多表联合查询等性能杀手了。所以海量数据的处理，对于大型交互类站点来说，是一个很大的问题，也是首先要解决的问题。因此，读写分离，分布式数据存储是新一带网站（高度交互和大型应用类站点）的CTO和决策层所不得不首要考虑的问题。

2、数据的并发和缓存
在某些时候，Web2.0和高度交互类站点的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而 当有多个用户或者进程同时对同一个资源或者列表进行更新操作的时候，应用程序可能会出现冲突，或者直接崩溃。这个时候，就需要一个好的数据并发处理策略以及缓存策略。 另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存这是就是一个大问题。 还有缓存的命中率也是一个值得注意的问题，如果缓存机制本身造成的命中率偏低，缓存不但不会提升性能，而且还有可能使网站系统付出高昂的代价。

3、海量文件存贮的问题
对于支持多种文件上传和分享的网站管理者来说，在庆幸硬盘容量越来越大的时候，我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当 用户量巨大时，文件的数量和需要的总体存储容量都将是海量的数据。在这种情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护和使用的时候磁盘的IO就是一个巨大的问题 。即便你有足够的带宽，但是你的磁盘也未必能响应过来。因为问题不是出在网络传输上。如果这个时候还涉及上传，磁盘很容易就会崩溃了。也许用raid和专用存贮服务器能解决 一时的问题，但是当同时上传的用户足够多时，又会出现新问题。这就需要做出能顺利横向扩展的分布式文件系统了。另外一个问题就是各地的访问问题，也许您的服务器在北京，可 是在广州或者西安的访问速度如何解决?如果做区域的分布式，那么您的文件索引以及架构该如何规划又是必须面对的问题了。 所以对我们来说，海量文件存贮是个很不容易的问题。

4、数据关系的处理
我们可以很容易的规划和设计出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN。但是，多对多关系 在高度交互的Web2.0时代需要有合理的解决模式，第三范式在这种情况是第一个应该被完全抛弃的。必须有效的把多表联合查询降到最低。数据关系优化，是必须认真对待的。

5、数据索引的问题
技术人员都知道，索引是提高数据库效率查询的最方面最廉价也最容易实现的方式。但是，在高数据写入和更新的情况下，update和delete付出的成本会高 得超出您的想象。有项目经验的资深技术人士都会遇到类似的情况，在更新一个聚焦索引的时候需要几分钟甚至更长时间来完成，那么对于一个网站来说，这基本上是用户不能忍受的。 索引和更新是一对天生的矛与盾，在做架构的时候，我们是需要认真设计这一块的，这也是数据结构优化的一个重要问题所在。

6、分布式处理
对于2.0网站由于其高互动性，CDN那种用于解决Web1.0访问性能问题的实现效果基本上无用武之地，因为内容是实时更新的。但是，我们仍然要要保证各地的访问速度， 那么，我们必须要面对一个的同样的问题，如何有效的实现数据同步和更新。实现各地服务器的数据的实时通讯又有是一个不得不考虑的问题。

7、数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许有人说我们可以用加密的，但是加密是否有效，以及加密解密的成本又如何规划呢。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq和各种网游的现状就能看出来这些问题)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的 数据时，IO、加密解密以及CPU的成本将会是非常高昂的。所以，数据安全对于高度交互的站点的技术团队来说。又是一个棘手的问题。

8、数据同步和集群的处理的问题
当我们的一台数据库服务器不堪重负的时候，我们就需要做基于数据库的负载和集群了。数据是基于网络传输的，数据以一种格式化的形式存储在某个库或者某个数据表中，而不管是数据 网络传输的延迟 ，还是访问数据库或者表的数据时，或者是这个DBMS运行的基础操作系统的IO瓶颈。这些性能问题，一个点，就足以破坏一整片。而这些问题又往往是不可避免的。因此，我们就需要通过 技术手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题 。当然，还有高可用的问题。这些也都是我们需要考虑和面对的。

9、数据的全文检索问题
这个问题对于一个数据量少、用户少的的小型站点 可能几局简单的SQL就搞定了，但是对于数据量大，用户群同样大的大型站点来说，情况就复杂了。要不Google也不会吃香了的，他的技术含量就体现在搜索上了。全文检索，搜索结果的缓存以及命中率，都是很有技术含量的问题，要提供给用户更好的服务，就必须有更好的算法，Google的成功就证明了这一点。所以，您要提供一定数量级数据的搜索服务，就一定会面对全文检索这个问题。

10、数据共享的渠道以及OpenAPI趋势 OpenAPI已经成为一个不可避免的趋势了，国外的facebook、google、myspace、yahoo等，国内的人人、海内、开心，都在考虑这个问题，它可以更有效的留住用户 ，并且激用户的参与度，给用户提供更多兴趣化的新工具，以及让更多的外围开发团队和开发者帮助您的站点提供最有效的开发，五分钟就是一个类似的典范。而这就一个有效的数据共享平台，数据开放平台就成为必不可少的途径了， 并且在开放接口的情况下还要保证数据的安全性和性能，这又是一个富有挑战性的问题了。