前言
最近，我在学习了解MySQL数据库架构相关的内容，从网上搜索了大量的相关资料和文章，粗粗阅览了一遍，发现架构相关的东西深不可测，需要非常丰富的知识阅历和实践经验。

我的阅历和经验明显不够用，所以我把了解到的相关内容作了下分类整理，算作这次学习的一个大致总结吧！这篇文章的大部分内容都来自网络，由于我的水平有限，整理的也并不准确，其中可能有很多错误之处，希望大家能不吝指正！希望这篇文章能抛砖引玉，帮助我们了解数据库架构相关的一些内容。

1 数据切分方案
当数据库比较庞大，读写操作特别是写入操作过于频繁，很难由一台服务器支撑的时候，我们就要考虑进行数据库的切分。所谓数据库的切分，就是我们按照某些特定的条件，将一台数据库上的数据分散到多台数据库服务器上。因为使用多台服务器，所以当一台服务器宕机后，整个系统只有部分数据不可用，而不是全部不可用。因此，数据库切分不仅能够用多台服务器分担数据库的负载压力，还可以提高系统的总体可用性。

数据的切分有两种方式:垂直切分和水平切分。

1.1 垂直切分
垂直切分就是按照系统功能模块，将每个模块访问的数据表切分到不同的数据库中。

适用情况：垂直切分适用于架构设计较好，各个模块间的交互点比较统一而且比较少，耦合度较低的系统。

优点：数据库的切分简单明了，规则明确；系统模块清晰明确，容易整合；数据维护方便，定位容易。

缺点：无法在数据库内实现表关联，只能在程序中实现；对于访问量大且数据量超大的数据表仍然会存在性能问题；事物处理会变得更为复杂，跨服务器的分布式事务会增多；过度切分会导致系统过度复杂、无法扩展、维护困难。

1.2 水平切分
水平切分就是对数据量超大的数据表，按照其中数据的逻辑关系，根据某个字段的某种规则，将其中的数据切分到多个数据库上。

适用情况：水平切分适用于有超大数据量的表且有合适的字段和规则进行水平切分的数据库。数据库进行水平切分后的多个数据库不应该存在交互的情况。

优点：可以在数据库内实现表关联；不会存在超大数据量且超高负载的数据表；可以在数据库内实现事务处理，事务处理相对简单；在合理的切分规则下，扩展性较好。

缺点：切分规则一般比较复杂，很难找出一个适合整个数据库的切分规则；数据的维护难度增加，人工定位数据难度增加；系统模块的耦合度较高，数据迁移拆分难度增加。

在实际进行数据切分时，我们首先应该根据系统模块的设计，合理地进行垂直切分。当模块细分到一定程度后，如果继续进行细分，就会使系统架构过于复杂，整个系统面临失控的危险。这时，我们就要利用水平切分的优势，来避免继续进行垂直切分导致的系统复杂化、面临失控的问题。同时，因为数据已经进行了合理的垂直切分，所以水平切分规则相对简单，系统模块耦合度较高的问题也已得到解决。总之，数据切分应该遵循一个原则，那就是“先合理垂直切分，再适时水平切分；先模块化切分，后数据集切分”。

2 数据整合方案
数据在经过垂直和水平切分被存放在不同的数据库服务器上之后，系统面临的最大问题就是如何来让这些来自不同数据库服务器上的数据得到较好的整合。解决这个问题有两种方式，第一种：在系统的每个模块中配置管理该模块需要的一个或者几个数据库及其所在服务器的信息，数据在模块中进行整合；第二种：通过中间代理层来统一管理所有的数据源，数据库集群对系统应用透明。第一种方案在初期开发时所需成本较小，但是长期来看，系统的扩展性会受到较大的限制。第二种方案则刚好相反，短期内付出的成本相对较大，但有利于系统的扩展。第二种方案可以通过一些第三方软件实现。

2.1 MySQLProxy
MySQLProxy可用来监视、分析、传输应用与数据库之间的通信。它可以实现连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。

原理：MySQLProxy 实际上是在应用请求与数据库服务之间建立了一个连接池。所有应用请求都发向MySQLProxy，然后经由MySQLProxy 进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer 上。对于多节点Slave集群，也可以起到负载均衡的效果。

优点：MySQLProxy具有很大的灵活性，我们可以最大限度的使用它。

缺点：MySQLProxy实际上并不直接提供相关功能，这些功能都要依靠自行编写LUA脚本实现。

2.2 Amoeba
Amoeba是一个基于Java开发的Proxy程序开源框架，致力于解决分布式数据库的数据整合问题。它具有Query路由，Query过滤，读写分离，负载均衡功能以及HA机制等。Amoeba可以整合数据切分后的复杂数据源，降低数据切分给整个系统带来的影响，降低数据库与客户端的连接数，实现数据的读写分离。

原理：Amoeba相当于一个SQL请求的路由器，它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库服务器上执行。据此实现负载均衡、读写分离、高可用性等需求。

优点：基于XML的配置文件，用SQLJEP语法编写规则，配置比较简单

缺点：目前还不支持事务；对返回大数量的查询并不合适；不支持分库分表，只能做到分数据库实例。

2.3 HiveDB
HiveDB也是一个基于Java开发，针对MySQL数据库提供数据切分及整合的开源框架。但是，目前的HiveDB仅支持数据的水平切分。HiveDB主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。

原理：HiveDB通过用户自定义的各种Partition keys将数据分散到多个数据库服务器上，访问时解析query请求，自动分析过滤条件，并行从多个数据库上读取数据后合并结果集返回给客户端应用程序。HiveDB的实现机制与Amoeba和MySQLProxy不同，它不用借助其他复制同步技术即可自行实现数据的冗余。其底层主要是基于Hibernate Shards 来实现的。Hibernate Shards是Google 技术团队在对 Google 财务系统数据 Sharding 过程中诞生的。Hibernate Shards是在框架层实现的，有其独特的特性：标准的 Hibernate 编程模型，会用 Hibernate 就能搞定，技术成本较低；相对弹性的 Sharding 策略以及支持虚拟 Shard 等。

优点：有商业公司支持，可自行实现数据冗余。

缺点：仅支持水平分区

在数据的整合过程中，还存在一些问题，比如：分布式事务的问题，跨节点JOIN的问题，跨节点排序分页的问题等。对于分布式事务的问题，我们需要将其拆分成多个单数据库内的小事务，由应用程序进行总控；跨节点JOIN的问题，我们需要先从一个节点中取出数据，然后由应用程序去其他节点进行JOIN或者使用Federated引擎；跨节点排序分页时，我们可以并行地从多个节点中读取数据，然后由应用程序进行排序分页。

3 数据冗余方案
任何设备或服务，只要是单点，就存在着很大的安全隐患。因为一旦这台设备或服务宕机之后，在短时间内就很难有备用设备或服务来顶替其功能。数据库作为系统的核心，必须存在一个备份以在出现异常时能够快速顶替原有服务，实现高可用性。同时，要实现数据库的读写分离，也必须采用复制技术保持多数据库节点的数据同步。实现数据同步的方式有很多，下面简要介绍常用的几个。

3.1 MySQL Replication
MySQL Replication是MySQL自带的一个异步复制的功能。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器，也就是主从模式。

原理：MySQL使用3个线程来执行复制功能。当开始复制时，从服务器会创建一个I/O线程连接主服务器并要求主服务器发送记录在其上的二进制日志中的语句。主服务器会创建一个线程将二进制日志中的内容发送到从服务器。从服务器I/O线程读取主服务器线程发送的内容并将该数据复制到从服务器数据目录中的本地文件中，这个文件称为中继日志。第三个线程是SQL线程，是由从服务器创建的，用来读取中继日志并执行日志中包含的更新。常用的架构方式为：主-从、主-主、主-从级联、主-主-从级联等。

优点：部署简单、实施方便，是MySQL自动支持的功能，主备机切换方便，可以通过第三方软件或者自行编写简单的脚本即可自动完成主备切换。

缺点：实际使用时，只能单主机进行写入，不一定能满足性能要求；服务器主机硬件故障时，可能会造成部分尚未传输至从机的数据丢失。

3.2 MySQLCluster
MySQL Cluster 是MySQL适用于分布式计算环境的高可用、高冗余版本，采用了NDB Cluster 存储引擎(“NDB”是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点)，允许在1个 Cluster 中运行多个MySQL服务器。

原理：MySQL Cluster将标准的MySQL服务器与NDB Cluster存储引擎集成了起来。MySQL Cluster由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster的数据节点，管理服务器，以及（可能）专门的数据访问程序。所有这些程序一起构成了MySQL Cluster。将数据保存到NDB Cluster存储引擎时，表（结构）被保存到了数据节点中，应用程序能够从所有其他MySQL服务器上直接访问这些表。 参见下图：

优点：可用性非常高，性能非常好；每一份数据至少在不同主机上面存在一份拷贝，且实时同步；通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。

缺点：维护比较复杂，很多情景下不适合使用。
3.3 DRBD磁盘网络镜像方案
DRBD(Distributed Replicated Block Device)，是由LINBIT 公司开发的，通过网络来实现块设备的数据镜像同步的一款开源Cluster软件，也被俗称为网络RAID1。

原理：DRBD介于文件系统与磁盘介质之间，通过捕获上层文件系统的所有IO操作，调用内核中的IO模块来读写底层的磁盘介质。当DRBD捕获到文件系统的写操作之后，会在进行本地的磁盘写操作的同时，以TCP/IP协议，通过本地主机的网络设备（NIC）将IO传递至远程主机的网络设备。当远程主机的DRBD监听到传递过来的IO信息之后，会立即将该数据写入到该DRBD所维护的磁盘设备。DRBD在处理远程数据写入的时候有三种复制模式，适用于不同的可靠性和性能要求情景。

优点：功能强大，数据在底层块设备级别跨物理主机镜像，可根据性能和可靠性要求配置不同级别的同步；IO操作保持顺序，可满足对数据一致性的苛刻要求。

缺点：非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本比较高。

3.4 RaiDB
RaiDB，其全称为RedundantArrays of Inexpensive Databases，也就是通过Raid理念来管理数据库的数据：通过将多个廉价的数据库实例组合到一个数据库阵列，提供比单台数据库更好的性能和容错性,同时隐藏分布式数据库的复杂性，提供给应用程序一个独立的数据库。

原理：在RaiDB中，控制器在数据库阵列的前面。应用程序发送请求到RaiDB控制器，控制器将请求分发给一组数据库。跟磁盘的Raid一样，RaiDB也有不同的级别或数据分发方案，如RaiDB-0、RaiDB-1、RaiDB-1-0、RaiDB-0-1等，用于提供不同的成本、性能、容错权衡。

优点：和磁盘的Raid一样，RaiDB也可以大幅提高数据的读写速度，并提供容错功能

缺点：只能支持将数据库中的表分割到不同的数据库实例上，数据表本身不能再进行分割了；不支持分布式的join；扩展性的提升取决于表的数目和各个表的负载情况。

4 数据缓存方案
4.1 Memcached
缓存是任何海量 Web 应用程序不可或缺的部分。Memcached是一个高性能的分布式内存对象缓存系统，用以减轻动态Web应用的数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高动态数据库驱动网站的访问速度。

原理：Memcached基于一个存储键/值对的hashmap，需要采用不同的方式来执行数据库的读取和写入操作。执行读取操作的顺序是从 Web 层获取（需要执行一次数据库查询的）请求并检查之前在缓存中存储的查询结果。如果找到所需的值，则返回它。如果未找到，则执行查询并将结果存储在缓存中，然后再将结果返回给 Web 层。在执行写入操作时，首先执行数据库写入操作，然后将之前缓存的任何受此写入操作影响的结果设定为无效，用以防止缓存和数据库之间出现数据不一致。

优点：大幅度地降低了数据库负载，更好地分配了资源，提供了更快速地数据访问；其守护进程（daemon）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。

缺点：不提供冗余，当某个服务器停止运行或崩溃时，所有存放在该服务器上的键/值对都将丢失；在需要Cache的数据对象较多的时候，应用程序所需要的代码量就会增加很多，同时系统复杂度以及维护成本也会直线上升。

5 全文检索方案
全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。好的检索方案不仅能提高检索效率，还能降低系统负载、节约系统成本。

5.1 Lucene
Lucene是一个开放源代码的全文检索引擎工具包。它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，还有部分文本分析引擎。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。目前已有一些对Lucene进行封装的解决方案，如Hibernate Search、Compass等。

原理：应用程序调用Lucene的相关API把数据库的数据写入并创建好索引，然后就可以调用Lucene所提供的数据检索API得到需要访问的数据，而且可以进行全模糊匹配。Lucene的数据也是存放在磁盘上而不是内存中，但是由于其高效的分词算法和索引结构，其效率非常的好。

优点：索引文件格式独立于应用平台；实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度；设计了独立于语言和文件格式的文本分析接口；已经默认实现了一套强大的查询引擎，用户无需自己编写代码即可使系统获得强大的查询能力，Lucene默认实现了布尔操作、模糊查询、分组查询等等。

缺点：不是完整的全文搜索引擎，需要开发人员进行大量的编码实现；配置比较复杂,应用难度大。

5.2 Hibernate Search
Hibernate Search是Hibernate对Lucene的一个集成方案，使用Java开发，用于对数据库中的数据进行检索。

原理：Hibernate Search通过对数据表中某些内容庞大的字段（如text字段）建立全文索引，然后对这些字段进行全文检索后获得相应的POJO，从而加快了对内容庞大字段进行模糊检索（sql语句中like匹配）的速度。

优点：功能强大，配置简单，只需要修改两个XML文件就可进行配置；支持Hibernate，以及EJB3 JPA标准应用；可以简单透明索引查询过的数据；支持通配符、多关键字、近义词、同义词、模糊查询等复杂检索，以及相关性排序等；支持搜索集群。

缺点：只支持Hibernate框架集成；应用示例很少，缺少参考资料。

5.3 Compass
Compass也是对Lucene的一个封装，是一个强大的，支持事务的开源搜索引擎框架。

原理：服务器启动时把需要建立索引的表中的数据全部取出，建立索引；在运行过程中，如果容器检测到数据有变动，需要更新索引，则添加或者删除索引。

优点：可以实时建立增量索引，不用定时重建索引；支持事务，可以直接对POJO进行保存；支持多种持久化框架(Hibernate、Struts、Spring等)。

缺点：不支持分类统计；API能力有限。

5.4 Solr
Solr也是一个开源的基于Lucene的高性能全文搜索服务器，采用Java5开发。它对Lucene进行了扩展，提供了比其更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。

原理：Solr对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过HttpGet操作提出查找请求，并得到XML格式的返回结果。

优点：具有高效、灵活的缓存功能和垂直搜索功能；可高亮显示搜索结果；通过索引复制提高了可用性；提供了一套强大的Data Schema来定义字段，类型和设置文本分析；提供了基于Web的管理界面。

缺点：分布式搜索的Master节点不容错。

5.5 Sphinx
Sphinx是一个用C++开发的基于SQL的全文检索引擎，可以结合MySQL，PostgreSQL做全文搜索，它可以提供比数据库本身更专业的搜索功能，使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计了搜索API接口，如PHP,Python,Perl,Ruby等，同时也为MySQL设计了一个存储引擎插件。

原理：Sphinx提供了indexer、searchd、search 3个应用程序，indexer用来创建索引，searchd用来启动全文检索服务，search作为客户端访问全文检索服务获取检索结果。Sphinx支持以增量的方式来建立索引：在第一次为需要检索的内容全部建立索引之后，以后每次重建索引时只为一段时间内新增或修改过的内容建立索引。创建的这些增量索引可以定时合并到主索引中。Sphinx在进行全文检索时默认会访问全部建立的索引，包括主索引和所有的增量索引。索引以何种方式创建对于应用来说是透明的，应用可以完全不必关心。

优点：高速索引 (在新款CPU上,近10 MB/秒)；高速搜索 (2-4G的文本量中平均查询速度不到0.1秒)；高可用性 (单CPU上最大可支持100 GB的文本,100M文档)；提供良好的相关性排名；支持分布式搜索；提供文档摘要生成；提供从MySQL内部的插件式存储引擎上搜索；支持每个文档多个全文检索域(默认最大32个)；支持每个文档多属性；支持断词；支持单字节编码与UTF-8编码；支持MySQ(MyISAM和InnoDB 表都支持)；支持PostgreSQL；支持多个平台（Windows、Linux、Unix、Mac等）。

缺点：必须要有主键，且必须为整型；不能进行灵活配置。

6 分布式并行计算方案
6.1 Google MapReduce
MapReduce是由Google公司发明的近些年来新兴的分布式计算模型，同时也是Google用C++开发的处理海量数据的编程工具。作为Google公司的核心技术之一，MapReduce在处理T级别以上的海量数据时有着卓越的表现。

原理：在我们输入数据的逻辑记录上应用map操作，来计算出一个中间key/value对集；在所有具有相同key的value上应用reduce操作，来适当地合并派生的数据。功能模型的使用，再结合用户指定的map和reduce操作，让我们可以非常容易的实现大规模并行化计算，同时使用重启作为初级机制可以很容易地实现容错。

优点：简化了跨节点的编程，使用非常方便，它隐藏了并行计算的细节，错误容灾，本地优化以及负载均衡，开发人员可以使用自己熟悉的语言进行开发，如Java，C#，Python，C++等；可以非常轻松的完成大型的计算需求；支持上千节点的大型集群，而且提供经过优化的错误容灾；扩展性强，可通过增加节点增强处理能力。

缺点：不适应实时计算应用的需求；在计算未全部完成前，无法查询到结果。

6.2 Hadoop
Hadoop 是一个开源的可运行于大规模集群上的分布式并行编程框架，是MapReduce思想的一个Java实现。由于分布式存储对于分布式编程来说是必不可少的，这个框架中还包含了一个分布式文件系统 HDFS( Hadoop Distributed File System )。

原理：在Hadoop的系统中，会有一台Master，主要负责NameNode的工作以及JobTracker的工作。JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave，每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。

优点：良好的可扩展性，系统管理员可以随时增删计算节点；分布式文件系统的备份恢复机制以及MapReduce的任务监控保证了分布式处理的可靠性；分布式文件系统的高效数据交互实现以及MapReduce结合LocalData处理的模式，可实现高效处理海量数据；框架可以运行在任何普通的PC上节约成本。

缺点：易用性不够；缺乏第三方产品支持；稳定性有待加强。

7 典型案例
7.1 Facebook
根据网络搜集到的资料，Facebook可能的部分架构如下：

Web前端是由PHP编写的,PHP程序由HipHop for PHP转换成 C++并用 g++编译，用于为模板和Web逻辑业务层提供高性能；业务逻辑以Service的形式存在，使用的是Thrift框架，根据需求的不同由PHP、C++、Java等实现；非用户相关的信息使用APC（The Alternative PHP Cache）缓存，用户相关的数据使用Memcached缓存；持久化由MySQL， Cassandra和HBase完成；页面加速使用Facebook定制的BigPipe技术；HTTP代理用Varnish Cache。

日志、点击、feeds等数据使用Scribe日志收集系统收集并存储于HDFS系统上，使用Hadoop和Hive进行分析处理。

Facebook并未公开其架构，以上内容为个人根据网络搜集资料进行的猜想。

7.2 人人网
根据网络上搜集到的相关资料来看，人人网的架构是不断演变的，每年的架构都不相同。2006年，人人网（校内网）刚创办上线时的架构比较简单。Squid cache用作HTTP代理服务器和Web缓存服务器；Resin用作Web服务器；使用MySQL（InnoDB引擎和主从结构）做持久化。2007年，随着业务的迅速发展，Web服务器改为LVS进行负载均衡的Resin群集，MySQL也改为群集并进行了垂直切分，开始大量使用Memcached进行数据缓存处理，同时基于ICE通信框架开发了位于MySQL和Resin中间的中间层服务，用于提供高并发低成本的数据访问。另外，还引入了Lucene进行全文检索。2008年，人人网开始开发开放API，引入了SOA（Service-oriented architecture，面向服务架构），同时由于业务量的大幅增加，MySQL进行了水平分区。另外，开始使用DFS（分布式文件系统）并引入了集群存储系统(龙存)。2008年以后，人人网开始拆分各个子系统，架构从紧耦合逐渐变为松耦合，MySQL也逐渐地被NoSQL取代，同时更加关注Graceful degradation和TCO（(Total cost of ownership)）。

从网络搜集到的资料来看，人人网目前采用的相关软件如下：

Nginx用来做跨IDC的请求代理；Resin用作Web服务器；Squid cache用作图片文件的反向代理；LVS提供四层负载均衡；ICE网络通讯框架被用来开发一些cache服务和逻辑服务；Netty网络框架被用来开发一些小服务；Struts框架已被自行开发的基于Spring技术的Rose Web框架所代替；基于Lucene的搜索集群提供搜人的服务；Memcached继续负责大部分缓存服务；持久化除MySQL外还有Tokyo Cabinet和人人网自行开发的Nuclear。大致的架构图如下：

参考资料
所有参考资料均来自网络:

1.《MySQL性能调优与架构设计-架构篇》: http://www.uml.org.cn/sjjm/20114062.asp

2.《MySQL架构方案》: http://www.cnblogs.com/RicCC/archive/2009/09/28/mysql-2.html

3.《Amoeba for Mysql》: http://amoeba.meidusa.com/wordpress/?page_id=4&cpage=3

4.《浅谈使用Mysql来搭建可扩展的SNS网站》: http://www.kuqin.com/database/20090408/44824.html

5.《SNS网站数据库技术分析》: http://database.51cto.com/art/201007/213668.htm

6.《分布式缓存系统Memcached入门指导》: http://database.51cto.com/art/200911/161720.htm

7.《分布式缓存系统memcached简介与实践》:http://developer.51cto.com/art/200902/108601.htm

8.《基于Java的Luncene的compass框架说明使用技术文档》:http://wenku.baidu.com/view/7b38294633687e21af45a97c.html

9. 《使用 Apache Solr 实现更加灵巧的搜索》:https://www.ibm.com/developerworks/cn/java/j-solr1/

10.《Apache Solr 的新特性》:http://www.ibm.com/developerworks/cn/java/j-solr-update/

11.《MapReduce》:http://en.wikipedia.org/wiki/MapReduce

12.《Google在新的内容索引系统中放弃MapReduce》:http://cloud.csdn.net/a/20100914/279436.html

13.《 Hadoop– 海量文件的分布式计算处理方案》:http://blog.csdn.net/calvinxiu/archive/2007/02/09/1506112.aspx

14.《用 Hadoop 进行分布式并行编程》:http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop1/

15.《百度高级架构师马如悦：我的Hadoop 2.0》:http://hi.baidu.com/youziguo/blog/item/cd185e564b51914d564e00fc.html

16.《Hadoop分布式文件系统：架构和设计》:http://hi.baidu.com/firefly0510/blog/item/4e9442dccde867e777c638c1.html

17.《Facebook Thrift》:http://group.mtime.com/ProgrammerLife/discussion/586818/

18.《揭秘Facebook的系统架构》:http://sd.csdn.net/a/20110426/296604.html

19.《What is Facebook’s architecture?》:http://www.quora.com/What-is-Facebooks-architecture

20.《人人网的系统架构网上搜集》:http://www.cnblogs.com/gym_sky/archive/2011/04/13/2015233.html

21.《TUP第二期人人网张铁安：Feed系统架构分析》:http://tech.sina.com.cn/it/2010-12-24/18135025494.shtml

22.《Graceful Degradation》:http://networking.ctocio.com.cn/whatis/349/7526349.shtml

23.《人人网使用的开源软件列表》:http://ugc.renren.com/2009/12/13/a-list-of-open-source-software-in-renren/

24.《Scribe+HDFS日志收集系统安装方法》:http://blog.csdn.net/jiedushi/archive/2011/05/13/6416816.aspx

25.《人人网技术架构介绍》，人人网，黄晶

26.《Google_MapReduce研究综述》，暨南大学信息科技学院07级研究生，周敏

27.《MySQL优化、新特性和新架构》，Alibaba DBA Team，彭立勋

28.《浅谈伪分布式数据库架构》，五分钟网络，金官丁

转自: http://blog.csdn.net/yongsheng0550/article/details/6592756