出于对互联网技术的热爱和本学期分布式数据库课程的需要，我在网上搜集了一些关于Facebook的技术资料，结合本学期学习的课程，在这里对Facebook的后台技术（主要是数据库技术）进行了一些简单的分析和总结。

众所周知的是，Facebook目前已经是全世界范围（除中国等少数国家之外）的最大的SNS（Social Networking Services）社交类网络，我们国内所经常使用的人人网(原名校内网）就是仿造其而来，比如从界面和类别（前台）上看，人人网的界面几乎和Facebook是一样的。但是两者所采用的后台技术则有所不同。Facebook的后台采用的是LAMP框架(Linux ,Apache ,Mysql,PHP)，而人人采用的是Java语言作为后台技术。

单从照片数据量来看，Facebook每个月超过几十亿张照片被上传，有超过30000台服务器，如果采用原始的集中式数据库，那么这么大的数据量以及高频率的访问几乎是不可想象的。自然而然得，Facebook采用的是分布式数据库，只不过作为一个巨型的，商业化的软件体系，它对于数据库的使用，远远比正常的书本上所描述的数据库要复杂的多，也要有效的多。

像刚才说过的Facebook采用的是LAMP框架，对于开源软件熟悉的人应该清楚，以上这四项软件，全部是开源的软件，我想Facebook这么做有两点原因，一是免费，二是这些开源的平台是经受的住时间的考验的，而且比如Mysql+PHP的组合也是非常受大家推崇的，其稳定性可以保证，但Facebook不是简单的把这几种工具拿过来使用，而是对这些开源的软件都进行了深度的改进。这也是我对Facebook极度崇拜的原因之一。

例如：

1.Facebook仍使用PHP，但它已经为它建立一个编译器（HipHop），以便它可以分为本地代码打开了Web服务器，从而提高性能。

2.Facebook使用Linux，但他特别为网络吞吐量做了优化。

3.Facebook使用MySQL，但主要是作为一个Key-value的持久性存储，Jions和服务器逻辑操作在Web服务器上操作。

4.Facebook也自己自主开发了一些软件，Haystack，一个高度可扩展的对象存储，用来存储Facebook的照片。还有Scribe，一个日志系统，可以运行在Facebook的巨大规模上的日志系统。

一、Facebook所使用的后台技术

 

下面首先列出，Facebook后台技术中所使用的主要软件，然后对其中的几个进行详细的描述。

1.Memcached

memcached的是现在互联网最有名的软件之一了。 这是一个分布式内存缓存系统，用来作为Web服务器和MySQL服务器之间的缓存层（因为数据库访问比较慢）。 多年以来，Facebook已经提出了一些优化Memcached和一些周边软件的办法。如压缩network stack。

2.HipHop for PHP

PHP作为一种脚本语言，和本地程序相比是运行缓慢的。 HipHop可以将PHP转换成C++代码，然后再进行编译，可以获得更好的性能。 因为Facebook严重依赖PHP，这使得其可以让Web服务器运行的更有效率。

3.Cassandra

Cassandra是一个不会单点失败的分布式存储系统。 这是为NoSQL运动的一个重要组成部分，并已公开的源代码（它甚至成为一个Apache项目）。Facebook在搜索功能中使用它。

4.Hadoop and Hive

Hadoop的是一个开源的map-reduce实现，使得它可以在进行大数据上进行运算。 Facebook的使用这个进行数据分析（而我们都知道，Facebook已经大量的数据）。 Hive就是发源于Facebook，使得对于Hadoop使用的SQL查询成为可能，从而是其更容易对非程序员使用。

5.Haystack

Haystack是Facebook的高性能照片存储/检索系统（严格来说，是一个对象存储，因此它并不一定要存储照片）。 它有许多工作要做;有超过20亿张上传的照片，并且每一个被保存在四个不同的分辨率，因此有超过80亿张照片。（具体见：《Facebook图片存储架构技术全解析》）

6.BigPipe

BigPipe是Facebook开发的一个动态的网页服务系统。 Facebook使用它来按section(称为“pagelets”)处理每个网页，以获取最佳性能。

7.Thrift

Facebook使用的几种不同的语言和不同的services。 PHP是最终用于前端，Erlang是用于聊天，Java和C ++也使用于多种场所，也许还有其他语言。Thrift是一个内部开发的跨语言的框架，联系语言，使他们可以在一起合作，从而使他们之间可以交互。 这使得Facebook可以更容易为继续保持其跨语言的发展。

8.Varnish

Varnish是一个HTTP加速器，可以作为一个负载平衡器，并缓存的内容，然后可以以闪电般的速度送达。Facebook使用Varnish来处理照片和个人资料图片，处理每天数十亿的要求。 和其他的东西一样，Varnish是开源的。

 

上面只是列出了Facebook所使用的技术的一部分，Facebook的应用中使用了非常多的技术，而今天，我将主要说的就是Facebook的Memcached和Cassandra。（两者都是与分布式系统相关的）以及NoSQL技术。

二、Facebook的数据库（NoSQL和Cassandra）

下图1疑似Facebook的数据库模型，（从网上找到的 不一定有可靠性）。

图1.Facebook数据模型

Facebook她采用的数据库体系毫无疑问是分布式的，像上面说的Facebook并不是一个传统意义上的LAMP站点，而MySQL也主要作为一个Key-value的持久性存储使用，而不是作为一个关系型数据库来使用，它的存储系统则是NoSQL运动的一个重要组成部分——Cassandra。

而要说明Facebook的Cassandra，首先要说一下一个新型的概念NoSQL.

1.NoSQL

1.1NoSQL起源

首先要澄清的是，NoSQL指的是非关系型的数据库。NoSQL=Not Only SQL，随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

SNS网站面临的主要问题有：

(1).High performance - 对数据库高并发读写的需求

(2).Huge Storage - 对海量数据的高效率存储和访问的需求

(3).High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

而传统的关系型数据库的很多特性对于现在的SNS系统是没有什么作用的：

(1).数据库事务一致性需求

(2).数据库的写实时性和读实时性需求

(3).对复杂的SQL查询，特别是多表关联查询的需求

 

而任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

 因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。

1.2NoSQL介绍

NoSQL数据库指那些非关系性的、定义不是很明确的数据存储仓库。NosQL数据库不再使用关系模型的概念，放弃了SQL数据库操作语句。NoSQL数据库克服了RDBMS的

缺点，可部署在廉价的硬件之上，支持分布式存储，能透明地扩展节点。典型的NoSQL数据库以key—values的形式存储数据，具有模式自由的特点。

Key-Values（CAP原则-  具体见下）：

key—values是NoSQL中的核心概念，是指一个键名对应一个键值，可以通过键名访问键值。

BASE（NoSQL相对于ACID的原则）：

BA：Basically Availble --基本可用

S：Soft-state --软状态/柔性事务

"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的

E：Eventual Consistency --最终一致性

BASE思想的主要实现有

              1.按功能划分数据库

              2.sharding碎片

 

1.3NoSQL优点

(1).便宜

(2).善于处理超大数据量的数据(TB or PB级别Search)

(3).高并发，不注重事务(ACDI的特性)，注重CAP原则(Consistency,Availability,Tolerance of network Partition)

(4).异于部署、扩展、开发

(5).相对于SQL(传统关系型数据库来讲)，是轻量级的应用

1.4NoSQL的产品

Name	Type	Store	Language
Memcached	K-V	Memory	C
MongoDB	K-V	Document	C++
GraphDB	Graph		C#
Neo4j	Graph		Java
Cassandra	K-V

 

前面说过Facebook中使用的数据库为MySQL ,但是它并不是被当做一个关系型数据库来使用的而是Key-Value的集合，这就为NoSQL准备了基础，而大体的介绍完NoSQL，我们开始介绍主角，Cassandra。

 

2.Cassandra

Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的Cassandra主要被Amazon的Dynamite团队来维护，（目前Cassandra是Apache的一个子项目，开源）并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外，twitter（世界顶级轻型博客门户，当然不包括我国）也曾使用Cassandra。

Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。

Cassandra是一套开源分布式Key-Value存储系统。

2.1 Cassandra特点

(1).分布式 　　

(2).基于column的结构化 　　

(3).高伸展性

Cassandra也支持比较丰富的数据结构和功能强大的查询语言。

2.2 Cassandra和其他数据库相比优点：

(1).模式灵活 ：使用Cassandra，像文档存储，你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部 署上。 　　

(2).真正的可扩展性 ：Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。 　

(3).多数据中心识别 ：你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。 　　

(4).范围查询 ：如果你不喜欢全部的键值查询，则可以设置键的范围来查询。 　　

(5).列表数据结构 ：在混合模式可以将超级列添加到5维。对于每个用户的索引，这是非常方便的。 　　

(6).分布式写操作 ：有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败

2.3Cassandra 的数据存储结构

Cassandra 的数据模型是基于列族（Column Family）的四维或五维模型。它借鉴了 Amazon 的 Dynamo 和 Google's BigTable 的数据结构和功能特点，采用 Memtable 和 SSTable 的方式进行存储。在 Cassandra 写入数据之前，需要先记录日志 ( CommitLog )，然后数据开始写入到 Column Family 对应的 Memtable 中，Memtable 是一种按照 key 排序数据的内存结构，在满足一定条件时，再把 Memtable 的数据批量的刷新到磁盘上，存储为 SSTable 。

2.4 Cassandra 的数据模型的基本概念：

1. Cluster : Cassandra 的节点实例，它可以包含多个 Keyspace

2.    2. Keyspace : 用于存放 ColumnFamily 的容器，相当于关系数据库中的 Schema 或 database

3. ColumnFamily : 用于存放 Column 的容器，类似关系数据库中的 table 的概念

4. SuperColumn ：它是一个特列殊的 Column, 它的 Value 值可以包函多个 Column

5. Columns：Cassandra 的最基本单位。由 name , value , timestamp 组成

下面是关于数据模型实例分析:

而且Cassandra还支持Java,C#,PHP Ruby等各种常用的编程语言来存储数据。

2.5Cassandra 集群中的节点状态的同步策略

很复杂，分析详见参考8.

 

以上对Cassandra的大体情况进行了简单的介绍，具体的内容可以到参考6到参考10 进行查找 而Cassandra也可以从Apache的网站上得到一个开源的版本。接下来，将介绍Facebook中存储缓存工具Memcached。

 

 

三、Facebook的缓存(Memcached)

缓存技术在后台架构中扮演着重要的角色。对于SNS站点来说，仅仅依靠数据库、Web服务器等软件的自身缓存机制是绝对不能满足要求的。 Memcached是人人网和Facebook都用到的一个分布式内存缓存系统。当然，缓存的手段是多种多样的，仅仅保证日常后台的稳定运行也是不够的。面对一些突发事件，缓存机制更是尤为重要，特别是在数据库服务器与Web服务器上。

　　

 

 

 

 

 

 

 

 

 

 

 

 

 

 

上图中，左边的是Facebook后台PHP的解析过程，右边的是Facebook中的缓存结构。

1.Memcached介绍

 

Memcached 是由 Danga Interactive 开发并使用 BSD 许可的一种通用的分布式内存缓存系统。而从上面给出的NoSQL产品表中我们也可以看到，Memcached是一个NoSQL产品，

Danga Interactive 开发 memcached 的目的是创建一个内存缓存系统来处理其网站 LiveJournal.com 的巨大流量。每天超过 2000 万的页面访问量给 LiveJournal 的数据库施加了巨大的压力，因此 Danga 的 Brad Fitzpatrick 便着手设计了 memcached。memcached 不仅减少了网站数据库的负载，还成为如今世界上大多数高流量网站所使用的缓存解决方案。

Memcached基于一个存储键/值对的hashmap。通过在内存里维护一个统一的巨大的hash表，Memcached能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。其守护进程（daemon ）是用C写的，但是客户端可以用任何语言来编写，并通过memcached协议与守护进程通信。但是它并不提供冗余（例如，复制其hashmap条目）；当某个服务器S停止运行或崩溃了，所有存放在S上的键/值对都将丢失。

 

2.Memcached用途及特点

用途：

1.使用多个Memcached实例，构建一个超大的分布式内存池。

2.分布式系统数据共享，提高应用的可扩展性，支持负载均衡。

特点：

·         协议简单

·         基于libevent的事件处理

·         内置内存存储方式

·         memcached不互相通信的分布式

 

Memcached处理的原子是每一个（key，value）对（以下简称kv对），key会通过一个hash算法转化成hash-key，便于查找、对比以及做到尽可能的散列。同时，memcached用的是一个二级散列，通过一张大hash表来维护。

 

Memcached有两个核心组件组成：服务端（ms）和客户端（mc），在一个memcached的查询中，mc先通过计算key的hash值来 确定kv对所处在的ms位置。当ms确定后，客户端就会发送一个查询请求给对应的ms，让它来查找确切的数据。因为这之间没有交互以及多播协议，所以 memcached交互带给网络的影响是最小化的。

 

缓存策略

Memcached采取LRU替换策略及每个kv对的有效时限。

缓存数据库查询

现在memcached最流行的一种使用方式是缓存数据库查询，下面举一个简单例子说明：

App需要得到userid=xxx的用户信息，对应的查询语句类似：

“SELECT * FROM users WHERE userid = xxx”

App先去问cache，有没有“user:userid”（key定义可预先定义约束好）的数据，如果有，返回数据；如果没有，App会从数据库中读取数据，并调用cache的add函数，把数据加入cache中。

当取的数据需要更新，app会调用cache的update函数，来保持数据库与cache的数据同步。

从上面的例子我们也可以发现，一旦数据库的数据发现变化，我们一定要及时更新cache中的数据，来保证app读到的是同步的正确数据。当然我们可 以通过定时器方式记录下cache中数据的失效时间，时间一过就会激发事件对cache进行更新，但这之间总会有时间上的延迟，导致app可能从 cache读到脏数据，这也被称为狗洞问题。（以后我会专门描述研究这个问题）

数据冗余与故障预防

从设计角度上，memcached是没有数据冗余环节的，它本身就是一个大规模的高性能cache层，加入数据冗余所能带来的只有设计的复杂性和提高系统的开支。

当一个ms上丢失了数据之后，app还是可以从数据库中取得数据。不过更谨慎的做法是在某些ms不能正常工作时，提供额外的ms来支持cache，这样就不会因为app从cache中取不到数据而一下子给数据库带来过大的负载。

同时为了减少某台ms故障所带来的影响，可以使用“热备份”方案，就是用一台新的ms来取代有问题的ms，当然新的ms还是要用原来ms的IP地址，大不了数据重新装载一遍。

另外一种方式，就是提高你ms的节点数，然后mc会实时侦查每个节点的状态，如果发现某个节点长时间没有响应，就会从mc的可用server列表里 删除，并对server节点进行重新hash定位。当然这样也会造成的问题是，原本key存储在B上，变成存储在C上了。所以此方案本身也有其弱点，最好 能和“热备份”方案结合使用，就可以使故障造成的影响最小化。

结语

本文主要是总结了一些网络上的关于Facebook后台技术的文章，并主要对其中的分布式技术（Cassandra和NoSQL、Memcached）作了简要的介绍，鉴于文章属搜集文章，借鉴了大量网络文章，在最后给出了相关引用和其他的进一步的阅读地址。

最后感觉这个总结对我于本门课程学习有很多用途，谢谢老师~
更多参考：

1.http://sebug.net/paper/databases/nosql/Nosql.html NoSQL数据库笔谈

2.http://baike.baidu.com/view/2677528.htm NoSQL百度百科

3.http://blog.csdn.net/DL88250/archive/2010/01/14/5191092.aspx 了解NoSQL必读的资料

4.卢冬海，何先波《浅析NoSQL数据库》， 《中国西部科技》 -2011年2期

5.http://css.dzone.com/articles/cassandra-nosql-database

6.Avinash Lakshman (Facebook),Prashant Malik(Facebook)《Cassandra - A Decentralized Structured Storage System》

7.http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandra/ 分布式 Key-Value 存储系统：Cassandra 入门

8.http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu1/index.html Cassandra 分布式数据库详解，第 1 部分：配置、启动与集群(等)

9.http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu2/ Cassandra 分布式数据库详解，第 2 部分：数据结构与数据读写

10.http://xulingbo.net/?p=203%A1%A2http://xulingbo.net/?p=211 Cassandra分布式数据库详解,第三部分：设计模式与技巧

11.http://www.ibm.com/developerworks/cn/java/j-memcached1/  Memcached 和 Grails，第 1 部分：安装和使用 memcached