大型网站系统架构分析--转
大型网站系统架构分析
原文地址：http://www.cnblogs.com/Mainz/archive/2009/04/28/1445424.html
千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？
首先讨论一下大型网站需要注意和考虑的问题。
- 数据库海量数据处理：负载量不大的情况下select、delete和update是响应很迅速 的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索 引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。
- 高并发死锁：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。
- 文件存储的问题：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高 并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京， 可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。
接下来讨论大型网站的底层系统架构，来有效的解决上述问题。
毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。
下面，就从服务器操作系统与Web服务器、数据库、服务器集群与负载均衡、缓存、独立的图片服务器、其它等几个方面来分析大型网站的系统架构。
服务器操作系统与Web服务器
最底层首先是操作系统。好的操作系统能提高好的性能、稳定性和安全性，而这些对大型网站的性能、安全性和稳定性都是至关重要的。
- 淘宝网（阿里巴巴）: Linux操作系统 + Web 服务器: Apache
- 新浪：FreeBSD + Web 服务器：Apache
- Yahoo：FreeBSD + Web 服务器：自己的
- Google: 部分Linux + Web 服务器：自己的
- 百度：Linux + Web 服务器: Apache
- 网易：Linux + Web 服务器: Apache
- eBay: Windows Server 2003/8 (大量) + Web 服务器：Microsoft IIS
- MySpace: Windows Server 2003/8 + Web 服务器：Microsoft IIS
由此可见，开源操作系统做Web应用是首选已经是一个既定事实。在开源操作系统中Linux和FreeBSD差不太多，很难说哪个一定比另外一个要 优秀很多、能够全面的超越对手，应该是各有所长。但熟悉Linux的技术人员更多些，利于系统管理、优化等，所以Linux使用更广泛。而Windows Server和IIS虽然有的网站使用，但不开源，而且需要购买微软的一系列应用产品，限制了其使用。总之，开源操作系统，尤其是Linux做Web应用 是首选已经是一个既定事实。
常用的系统架构是:
- Linux + Apache + PHP + MySQL
- Linux + Apache + Java (WebSphere) + Oracle
- Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库
数据库
因为是千万人同时访问的网站，所以一般是有很多个数据库同时工作的，说明白一点就是数据库集群和并发控制，数据分布到地理位置不同的数据中心，以免发生断电事故。
主流的数据库有Sun的是MySQL和Oracle。
Oracle是一款优秀的、广泛采用的商业数据库管理软件。有很强大的功能和安全性，可以处理相对海量的数据。而MySQL是一款非常优秀的开源数 据库管理软件，非常适合用多台PC Server组成多点的存储节点阵列(这里我所指的不是MySQL自身提供的集群功能)，每单位的数据存储成本也非常的低廉。用多台PC Server安装MySQL组成一个存储节点阵列，通过MySQL自身的Replication或者应用自身的处理，可以很好的保证容错(允许部分节点失 效)，保证应用的健壮性和可靠性。可以这么说，在关系数据库管理系统的选择上，可以考虑应用本身的情况来决定。
MySQL数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。
服务器集群与负载均衡
服务器群集中每个服务结点运行一个所需服务器程序的独立拷贝，而网络负载均衡则将工作负载在这些主机间进行分配。负载均衡建立在现有网络结构之上，它提供了一种廉价有效的方法扩展服务器带宽和增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。它主要完成以下任务:解决网络拥塞问题，服务就近提供，实现地理位置无关性 ;为用户提供更好的访问质量;提高服务器响应速度;提高服务器及其他资源的利用效率;避免了网络关键部位出现单点失效。
常用的服务器集群和数据库集群负载均衡实现方法：
- Citrix NetScaler的硬件负载均衡交换机做服务器集群的负载均衡。
- MySQL Proxy做MySQL服务器集群的负载均衡并实现读写分离。其实现读写分离的基本原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。
- CDN (Content Delivery Network): 几乎在各大网站都有使用该技术。例如，使得你的网站在各省市访问更快，其原理是采取了分布式网络缓存结构（即国际上流行的web cache技术），通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的cache服务器内，通过DNS负载均衡的技 术，判断用户来源就近访问cache服务器取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的 加速器，以达到快速、可冗余的为多个网站加速的目的。
缓存
众所周知，使用缓存能有效应对大负载，减少数据库的压力，并显著提高多层应用程序的性能，如果某个用户多次请求同一资源，则可以从缓存返回该资源， 从而避免了重新从服务器或数据库请求该资源而产生的系统开销。缓存可以通过减少获取请求的资源所需的时间，提高应用程序性能。缓存还可以通过减少到服务器 的往返次数，降低网络通信量。尽管缓存可以提高性能，但它也增加了返回到应用程序的资源可能变得陈旧的风险。这意味着，返回的资源可能与假设没有使用缓存 的情况下，服务器有可能发送的资源并不完全相同(即取得“脏数据”)。
即便如此，简单的缓存策略也能大大提升网站性能。例如，Youtube把首页最新的视频列表缓存60秒，也就是说60秒内并发的request都是从缓存读取的，大大减少了数据库压力。再加上CDN，使得Youtube首页的并发访问速度很快。
单机内存缓存、文件缓存、数据库缓存等的策略都是可以很简单的实现的，例如可以使用微软的Caching Application Block，但如何在集群环境中使多个缓存、多层缓存并保存同步是个重大问题。大型网站一般都使用缓存服务器群，并使用多层缓存。业内最常用的有：
- Squid cache，Squid服务器群，把它作为web服务器端前置cache服务器缓存相关请求来提高web服务器速度。Squid将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载
- memcache，memcache服务器群，一款分布式缓存产品，很多大型网站在应用; 它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这 些HashTable。因为通常网站应用程序中最耗费时间的任务是数据在数据库的检索，而多个用户查询相同的SQL时，数据库压力会增大，而通过 memcache的查询缓存命中，数据直接从memcache内存中取，每次缓存命中将替换到数据库服务器的一次往返，到达数据库服务器的请求更少，间接 地提高了数据库服务器的性能，从而使应用程序运行得更快。它通过基于内存缓存对象来减少数据库查询的方式改善网站系统的反应，其最吸引人的一个特性就是支 持分布式部署。有关memcache，以下文章可以参考：参考1，参考2，参考3官方站点。
- e-Accelerator，比较特殊，PHP的缓存和加速器。是一个免费开源的PHP加速、优 化、编译和动态缓存的项目，它可以通过缓存PHP代码编译后的结果来提高PHP脚本的性能，使得一向很复杂和离我们很远的 PHP脚本编译问题完全得到解决。通过使用eAccelerator，可以优化你的PHP代码执行速度，降低服务器负载，可以提高PHP应用执行速度最高 达10倍。
独立的图片服务器
无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。
其他
一个互联网应用，除了服务器的操作系统，Web Server软件，应用服务器软件，数据库软件外，我们还会涉及到一些其他的系统，比如一些中间件系统、文件存储系统（图片服务器，视频服务器，管理服务 器，RSS和广告服务器等等）、全文检索、搜索、等等。会在以后介绍。
或许您对以下相关文章有兴趣：
