《
如何构架一个大型网站_》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/110AM2012.htm
索引和更新是一对生成的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是破费时光最多的问题。
这里的大型网站架构只包含高互动性高交互性的数据型大型网站，基于大家众所周知的起因，我们就不谈消息类和一些依附HTML静态化就可以实现的架构了，我们以高负载高数据交流高数据流动性的网站为例，比QQ校友，校内网，开心网等相似的web2.0系列架构。我们这里不讨论是PHP仍是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的上风在于实现而不是好坏，不管你抉择任何语言，架构都是必须要面对的。
1、海量数据的处理
3、文件存贮的问题
2、数据并发的处理
8、数据保险性的分析
这里探讨一下大型网站须要留神跟斟酌的问题
10、数据共享的渠道以及OPENAPI趋势
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输依据数据库的设计的不同，数据延迟是很恐怖的问题，也是不可防止的问题，这样的话，我们就需要通过另外的手腕来保障在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比方数据散列，宰割，内容处理等等问题。
7、Ajax的利弊剖析
6、分布式处理
对于2.0网站因为其高互动性，CDN实现的后果基础上为0，内容是实时更新的，我们惯例的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通信有是一个不得不需要考虑的问题。
家喻户晓，对于一些绝对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，自身负载量不是很大，最多再加多少个索引就可以搞定。对于大型网站，天天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是不任何问题的，但是跟着用户的增长，数据量会是几何级的增加的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的本钱的十分高的。
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对缓存，在高并发高处置的时候也是个大问题。在全部利用程序下，缓存是全局共享的，然而在咱们进行修正的时候就，假如两个或者多个恳求同时对缓存有更新的请求的情形下，运用程序会直接的逝世掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。
5、数据索引的问题
4、数据关系的处理
9、数据同步和集群的处理的问题
-->
对于HTTP协定来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的进程就可能是明文了(好比我们晓得的QQ，可以很容易的判定他的加密，并有效的写一个跟他一样的加密和解密方式出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会相继而来(从qq一开端的群发可见端倪)。也许我们可以很的意的说，我们可以采取更高等别的断定甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家乐意尝尝，实际上并不是很难。
成也AJAX，败也AJAX，AJAX成为了主流趋势，忽然发明基于XMLHTTP的post和get是如斯的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很畸形的AJAX要求。但是在AJAX处理的时候，如果我们应用一个抓包工具的话，对数据返回和处理是高深莫测。对于一些盘算量大的AJAX请求的话，我们可以结构一个发包机，很容易就可以把一个webserver干掉。
众所周知，索引是进步数据库效力查询的最方面最便宜最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无奈想想，笔者碰到过一个情况，在更新一个聚焦索引的时候需要10分钟来实现，那么对于站点来说，这些根本上是不可忍耐的。
我们能够很轻易的计划出一个合乎第三范式的数据库，里面充满了多对多关联，还能用GUID来调换INDENTIFY COLUMN 然而，多对多关系充满的2.0时期，第三范式是第一个应当被摈弃的。必需有效的把多表结合查问降到最低。
对于一些支撑文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的计划是对文件依照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么保护的时候和使用的时候磁盘的Io就是一个宏大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还波及上传，磁盘很容易就over了。
所以我们不得不否认，文件存贮是个很不容易的问题
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，兴许我们的服务器在北京，可能在云南或者新疆的拜访速度如何解决?如果做散布式，那么我们的文件索引以及架构该如何规划。
Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到21kaiyun.com，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴致以及让更多的人辅助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的道路了，而在开放的接口的情况保证数据的平安性和机能，又是一个我们必需要当真思考的问题了。
另外，就是数据库的死锁问题，也许平时我们感到不到，死锁在高并发的情况下的呈现的概率是无比高的，磁盘缓存就是一个大问题。
对于大型网站架构必须考虑的10条问题，很全面，推举浏览！
相关的主题文章：
(责任编辑：网站建设)
如何构架一个大型网站_相关文章