程序都是跑在机器上的，并行CPU包含几个部分。

• 处理器核心。执行线程的设备。一个核心可以执行一个或多个线程(超线程)
• 互连线。处理器和处理器，处理器和储存器之间的通信通道。一般CPU分两种架构，SMP对称多处理器和NUMA架构。SMP的通信是总线式的，核心增加后性能会下降。NUMA的结果相当于以太网，性能相对较好。理论上NUMA是没有cache的,不过商业产品都有。互连线的资源是有限的。
• 存储器。这里存储器值得是一级缓存，二级缓存和内存。一级缓存一般和处理器在一起，访问它需要1-2个时钟周期，访问二级缓存则需要数十个时钟周期。而访问内存，需要数百个时钟周期。

布隆过滤器的原理不难理解。相对于一个精简的HashMap的数据结构，存入数据的时候，不存入数据本身，只保存其Hash的值。可以用于判断该数据是否存在。其本质是用Hash对数据进行"有损压缩"的位图索引。详细参见。

错误率

如果用来存放Hash值的槽位足够多，那么碰撞的概率就会比较小。但是所占用的空间就会比较大。所以当分配空间的时候，需要通过你能容忍的错误率和需要存放的Key的数量来指定。如果所需存储的Key数量是n,错误率是p，所需要的槽位是m。有计算槽位的公式$m=-\frac{n\ln p}{(\ln 2)^2}.$，也有计算概率的公式$p = \left( 1-e^{-(m/n\ln 2) n/m} \right)^{(m/n\ln 2)}$。这些公式当然不是我推导出来的，想来也不太难，就不赘述推导过程了。下面这张图可以很好的表示n和m取不同的值的时候，p的值。

根据这张图。我们可以计算出所需要的内存使用量。如果把错误率控制在1%以下的话。

可见占用的空间在key的数量在百万级别还是很划算的，但到了上亿的级别就不那么划算了。

Bloom Filter的插入和查询都是常数级别的，所以最大的问题就是占用内存过大。而初次分配内存的时候，如果没有能够确认槽位的个数。如果分配过多会导致内存浪费，太少就会倒是错误率过高。下面提到的两个改进方案可以分别解决这两个问题。

折叠

折叠是指当你初始化一个Bloom Filter的时候，可以分配足够大的槽位，等到Key导入完毕后，可以对使用的槽位进行合并操作。具体方法是将槽位切成两半，一边完全叠加到另一边上。减少内存的使用量。检查key的代码要做稍许改变。例：

通过这个操作，可以使实际使用的内存量减半。多执行几次，能减少更多。

动态扩展

通过折叠操作，可以解决分配过大的问题，但是如果一开始分配过小，就需要扩展槽位才行。如何扩展呢？只要按原尺寸再建立一个Bloom Filter数组。原来的那个保存起来，不再写入。有新的写请求的时候，就将数据写入到新的那个Bloom Filter数组里面去。等到新的也写满了，就再建立一个，以此类推。查询的时候，就需要遍历每一个Bloom Filter数组才行。但因为查询一个Bloom Filter数组的速度很快，查询一组Bloom Filter数组也不会太影响性能。使用这种手段可以是Bloom Filter的大小可以轻易的扩展。但这样做有个的缺陷，就是错误率会随着数组的增加而上升，因为实际的数组长度并没有增加。

通过上面的两个方法，就可以解决BloomFilter的分配内存的问题。但无论哪种方法都有自己局限性，折叠每次只能减半，不是很精确。动态增加的方法会造成错误率增加。最好还是能预先估计到这个BloomFilter的容量。

代码优化

线程数要大于等于核数

如果使用多线程，只有运行的线程数比核数大，才有可能榨干CPU资源，否则会有若干核闲置。要注意的是，如果线程数目太多，就会占用过多内存，导致性能不升反降。JVM的垃圾回收也是需要线程的，所以这里的线程数包含JVM自己的线程

尽量减少共享数据写操作

每个线程有自己的工作内存，在这个区域内，系统可以毫无顾忌的优化，如果去读共享内存区域，性能也不会下降。但是一旦线程想写共享内存(使用volatile关键字)，就会插入很多内存屏障操作(Memory Barrier或者Memory Fence)指令，保证处理器不乱序执行。相比写本地线程自有的变量，性能下降很多。处理方法是尽量减少共享数据，这样也符合"数据耦合"的设计原则。

使用synchronize关键字

在Java1.5中，synchronize是性能低效的。因为这是一个重量级操作，需要调用操作接口，导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象，性能更高一些。但是到了Java1.6，发生了变化。synchronize在语义上很清晰，可以进行很多优化，有适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地。

使用乐观策略

传统的同步并发策略是悲观的。表现语义为：多线程操作一个对象的时候，总觉得会有两个线程在同时操作，所以需要锁起来。乐观策略是，假设平时就一个线程访问，当出现了冲突的时候，再重试。这样更高效一些。Java的AtomicInteger就是使用了这个策略。

使用线程本地变量(ThreadLocal)

使用ThreadLocal可以生成线程本地对象的副本，不会和其他线程共享。当该线程终止的时候，其本地变量可以全部回收。

类中Field的排序

可以将一个类会频繁访问到的几个field放在一起，这样他们就有更多的可能性被一起加入高速缓存。同时最好把他们放在头部。基本变量和引用变量不要交错排放。

批量处理数组

现在处理器可以用一条指令来处理一个数组中的多条记录，例如可以同时向一个byte数组中读或者写store记录。所以要尽量使用System.arraycopy()这样的批量接口，而不是自己操作数组。

JVM优化

启用大内存页

现在一个操作系统默认页是4K。如果你的heap是4GB，就意味着要执行1024*1024次分配操作。所以最好能把页调大。这个配额设计操作系统，单改Jvm是不行的。Linux上的配置有点复杂，不详述。

在Java1.6中UseLargePages是默认开启的，LasrgePageSzieInBytes被设置成了4M。笔者看到一些情况下配置成了128MB，在官方的性能测试中更是配置到256MB。

启用压缩指针

Java的64的性能比32慢，原因是因为其指针由32位扩展到64位，虽然寻址空间从4GB扩大到256 TB，但导致性能的下降，并占用了更多的内存。所以对指针进行压缩。压缩后的指针最多支持32GB内存，并且可以获得32位JVM的性能。

在JDK6 update 23默认开启了，之前的版本可以使用-XX:+UseCompressedOops来启动配置。

性能可以看这个评测，性能的提升是很可观。



启用NUMA

numa是一个CPU的特性。SMP架构下，CPU的核是对称，但是他们共享一条系统总线。所以CPU多了，总线就会成为瓶颈。在NUMA架构下，若干CPU组成一个组，组之间有点对点的通讯，相互独立。启动它可以提高性能。

NUMA需要硬件，操作系统，JVM同时启用，才能启用。Linux可以用numactl来配置numa,JVM通过-XX:+UseNUMA来启用。

激进优化特性

在Java1.6中，激进优化(AggressiveOpts)是默认开启的。激进优化是一般有一些下一个版本才会发布的优化选项。但是有可能造成不稳定。前段时间以讹传讹的JDK7的Bug，就是开启这个选项后测到的。

逃逸分析

让一个对象在一个方法内创建后，如果他传递出去，就可以称为方法逃逸；如果传递到别的线程，成为线程逃逸。如果能知道一个对象没有逃逸，就可以把它分配在栈而不是堆上，节约GC的时间。同时可以将这个对象拆散，直接使用其成员变量，有利于利用高速缓存。如果一个对象没有线程逃逸，就可以取消其中一切同步操作，很大的提高性能。

但是逃逸分析是很有难度的，因为花了cpu去对一个对象去分析，要是他不逃逸，就无法优化，之前的分析血本无归。所以不能使用复杂的算法，同时现在的JVM也没有实现栈上分配。所以开启之后，性能也可能下降。

可以使用-XX:+DoEscapeAnalysis来开启逃逸分析。

高吞吐量GC配置

对于高吞吐量，在年轻态可以使用Parallel Scavenge,年老态可以使用Parallel Old垃圾收集器。
使用-XX:+UseParallelOldGC开启

可以将-XX:ParallelGCThreads根据CPU的个数进行调整。可以是CPU数的1/2或者5/8

低延迟GC配置

对于低延迟的应用，在年轻态可以使用ParNew,年老态可以使用CMS垃圾收集器。

可以使用-XX:+UseConcMarkSweepGC和-XX:+UseParNewGC打开。

可以将-XX:ParallelGCThreads根据CPU的个数进行调整。可以是CPU数的1/2或者5/8

可以调整-XX:MaxTenuringThreshold(晋升年老代年龄)调高，默认是15.这样可以减少年老代GC的压力

可以-XX:TargetSurvivorRatio，调整Survivor的占用比率。默认50%.调高可以提供Survivor区的利用率

可以调整-XX:SurvivorRatio,调整Eden和Survivor的比重。默认是8。这个比重越小，Survivor越大，对象可以在年轻态呆更多时间。

等等

参见：《Java优化白皮书》，《深入理解Java虚拟机》

HBase – Hadoop Database，是一个构建在Apache Hadoop上的列数据。Hbase有很好的扩展性，被认为是BigTable的一个克隆，可以存储数以亿计的行。

在Hbase的官网，我们看到一篇很好的官方文档。我花了很长的时间，把他汉化了。请点击这里:《HBase中文官方文档》

这篇文档非常的详尽，从Hbase的安装，配置，使用，原理，优化，维护都做了非常全面的介绍。还提供了很多扩展阅读，方便我们知道更多Hbase的工作机制。通过翻译这篇文档，我细细读了这篇文档，受益良多。

翻译是一个吃进去再吐出来的过程，我的Hbase的理解也可能会发生一些偏差，所以如果有地方发生错误，请告诉我，大家一起进步。

我曾经花了很多脑筋来找一个很好很完美的哈希算法，但都没有想到，最近看到了，掩不住一阵激动分享下。最小完美哈希函数是什么，要从定义说起，这个名字很长，一步步解释。

1. 哈希函数 任意函数h(x)都可以说哈希函数，一般来说，一个良好的哈希函数可以尽量避免重复。x的集合是参数域，h(x)的集合是值域。
2. 完美哈希函数  完美哈希函数，就是完全不会冲突的哈希函数，这要求函数的值域至少比参数域要大
3. 最小完美哈希函数 最小完美哈希函数，就是指函数的值域和参数域的大小完全相等，一个也不多
4. 保序最小完美哈希函数 保序的意思就是指这个哈希之后顺序是不变的，同时还能满足其他两个条件。

这里的h就可以最小完美哈希函数算出的值了，很神奇，不是吗？

大致的流程走了一遍，现在最最关键的是h1(x),h2(x)和g(x)是怎么得来的。

h1(x)和h2(x)比较简单，可以使用一个很简便的方法获得：先定义一个权重数组w[i],这个数据是一系列随机的数。$h1=(t[1]*w[1]+t[2]*w[2]+...+t[i]*w[i])\ mod\ m$。其中t[i]指得的字符串x的第i个字符,m值得的函数的值域。只要更换一个权重数组，就可以重新构造一个新函数。有很多方法可以构造这两个函数。

g(x)的获得就比较复杂。可以是凑出来的。就如同上面的例子，因为$g(5)+g(9)\ mod\ 12=0$,$g(5)+g(7)\ mod\ 12=1$。所以我们可以凑出$g(5)=0,g(7)=1,g(9)=0$这样就可以满足上面的两个条件了。需要一个数组来存储函数g的结果，当然凑也不能瞎凑，是有方法的，下面专门讲凑的步骤。

如果直接在Shell中调用这个程序，程序会很快结束，不会僵死。

为什么会堵塞呢，原因是当调用exec(cmd)后，JVM会启动一个子进程，该进程会与JVM进程建立3个管道连接，标准输入，标准输出和标准错误流。假设该程序不断在向标准输出流和标准错误流写数据，而JVM不读取，数据会暂时缓冲在Linux的缓冲区，缓冲区满后该程序将无法继续写数据，会僵死，所以Java程序就会僵死在waitfor()，永远无法结束。

解决办法就是增加两个线程，一个线程负责读标准输出流，另一个负责读标准错误流，这样子数据就不会积压在缓冲区，程序就能够顺利运行。

查看源代码后，还发现一个潜在的问题。但程序执行到exec的时候，JVM会使用管道，占有3个文件句柄，但程序运行结束后，这三个句柄并不会自动关闭，这样最终会导致java.io.IOException: Too many open files。所以就算外部程序的没有输出，也必须关闭句柄：

我们发觉当调用close()方法后,JVM并不会立即回收句柄，具体的回收时间不确定。另外如果不调用close(),句柄也会被回收，也可能发生“Too many open files”的错误。根据这篇文章，不同的垃圾收集器会选择不同的回收策略。所以最好还是要关闭。

总结
1.如果外部程序有大量输出,需要启动额外的线程来读取标准输出和标准错误流
2.必须关闭三个句柄

另外编写了一个工具类来方便使用，本来两行代码确要写成这么长，有点小折腾了。感兴趣的可以在这里下载：

片段一

丁丁哥哥的身材很好，他和那些书呆子们不同，他喜欢体育，很早赤膊。在五月里，他就开始光着上身，对着篮球架引体向上。他可以做三十下，我可以做三下。他教我如何双手握着篮球架上的横杠在上面转一圈，我一个夏天都喜欢供着篮球架打转，我衣服的腹部都是锈水。丁丁哥哥有一次甚至把篮球架都拔了起来，换了一个地方，因为他说篮球架在的地方
不好，他在学习的时候每天都要看到，让他分心。
我相信，丁丁哥哥那天是去找了临时工哥哥，并且把他痛打一顿。但是丁丁哥哥后来告诉我，他只是去谈了谈，他说打架当然能解决问题，谈也能解决问题。我说，那你为什么不像香港电影里那样，直接就打架呢？
丁丁哥哥沉思许久，意味深长地看着我，把手放在我的肩膀上，说，因为会疼嘛。
我点了点头。
丁丁哥哥说，他在学校里是学生会的主席，有的事情，靠谈就搞定了，他有领导能力。丁丁哥哥说，那天，我去找了临时工哥哥，问他缘由，因为像我们这种大人，是不会打弹子的。
我看着丁丁哥哥，丁丁哥哥一点头，继续说，果然。
我一精神，问，那是为什么呢，他要和我们打弹子。
丁丁哥哥说，因为他要赢你们的弹子，他不光和你们打，他还和别的小孩子打，因为他要买一只红灯牌录音机。
我说，嗯。
丁丁哥哥秀了一下肱二头肌，说道，我说，你这是不可以的，你这是欺负小孩子。你要录音机干什么？他说，他要录一盘磁带，唱一首歌寄给他的笔友。
我说，他可以去借一台录啊。
丁丁哥哥说，总是有私心的嘛，他当然也想自己听听，后来我就带他去了文化站，借了我一个朋友的录音机。
我说，哇，文化站的人你也认识啊。
丁丁哥哥云淡风轻道，一个朋友。
我说，那临时工哥哥唱了一首什么歌啊。
丁丁哥哥说，他录了一首《尘缘》。
我说，什么是《尘缘》啊？
丁丁哥哥说，你爸妈不看电视啊，主题歌。
我说，嗯。
丁丁哥哥哼道，尘缘如梦，几番起伏总不平，繁华落尽，一身憔悴在风里，回头时无晴也无雨，漫漫长路，起伏不能由我，人海漂泊，尝尽人情淡薄，热情热心，换冷淡冷漠，任多少真情独向寂寞，人随风过，自在花开花又落，不管世间沧桑如何
我打断了丁丁哥哥，笑道，哈哈哈哈哈哈，临时工哥哥也会唱歌，临时工哥哥也会唱歌。
我没有意识到，那一刻是丁丁哥哥在唱歌，这是我第一次听他唱歌，但是我却打断了他，
丁丁哥哥看着我说，漫漫长路，起伏不能由我。
我跟着唱道，漫漫长路，起伏不能由我。
丁丁哥哥说，这是去年的歌，今年唱着还挺有感觉。
我跟着说，挺有感觉！
丁丁哥哥答应在那个夏天教我足球中的假动作，丁丁哥哥说我踢球太老实了，往左就是往左，往右就是往右，你的身体已经告诉了对手一切。你要把球踢好，要把球控制在自己的脚下，就要学会假动作，你眼睛看着右边，身体晃向右边，你伸出右脚，大家都以为你要往右去了，突然之间，你的左脚一发力，你其实是向左去了，你就把大家都骗了，踢球过人一定要做假动作。等我回来我就教你假动作。
丁丁哥哥在春天收拾好所有的行囊，握着一张火车票向我告别。
我说，丁丁哥哥，你要去南方还是要去北方啊。
丁丁哥哥说，我要去北方。
我说，哇，带我一起去吧。
丁丁哥哥说，不行，你太小了。
我说，我坐火车不用钱的。
丁丁哥哥说，不行，你太大了。
我说，丁丁哥哥，你去做什么啊？
丁丁哥哥说，我去和他们谈谈。
我说，你和谁谈谈啊？
丁丁哥哥唇边露出微笑，急切地说，这个世界。
我说，哇噢。
如果丁丁哥哥还活着，现在应该是 38 岁？39 岁？40 岁？我已经迷糊了。娜娜买了两大塑料袋的食物向我走来。没走几步，就扶着垃圾桶吐了起来。我赶紧打开车门，门边正好撞到一个推着液化气罐的老大爷。我没顾上，径直穿过马路。老大爷大喝一声，小伙子，你站住，撞了人想跑？

从这段话韩寒对丁丁哥哥有比较全面的介绍。丁丁哥哥身体很健壮，并且非常爱好学习，是学生会的主席。他还说“打架当然能解决问题，谈也能解决问题”，同时表示更期望和平解决问题。唱出那首《尘缘》，颇有诀别的意味。在春天出发去北方，答应会在夏天来教“我”踢球，可以却没有能回来。去北方的目的是“和这个世界谈谈”。如果大学四年的话，他上大学的年代大约在1987-1993之间。

片段二

10 号的性格从小这样，在他小的时候，周围有不少人讨厌他，但这就是我没有讨厌他的原因， 我觉得他就是一个粗制滥造没有文化的丁丁哥哥，他们是事物的两个方向，但却是同一样事物。10 号那样滥，但有时候能泛出亮光。丁丁哥哥虽然总是充满光
芒，但他也有背对着我们的光斑。
在这个夏天湿漉漉的夜晚，10 号直接抽出一把枪，说，兄弟，你玩玩。
我忙摆手，问他，真的假的。
10 号说，当然是真家伙，假的带在身上，那还不被兄弟们笑死。
我说，你哪里来的。
10 号说，你不知道吧，小时候小学的校办厂，它原来就是生产枪的。我他妈也是到后来才知道，你看，我要了这个型号，陆四式，—枪—个。
我看了一眼，说，你开过么？
10 号举起枪，朝天砰的一枪，回声在这个小镇上飘荡撞击了三四次，我抬头望去，刺眼的月光和若隐若现的树叶摇曳着。10 号乐不可支，看着我，说，开过了。
10 号搂着我的肩膀，我们坐在一个公共汽车站前，10 号说，娘的，这个娘们。我最近撩上了一个女的。哦，我先跟你说，前两天我还看到了一个片子．一个电影，讲少年杀人事件的，但是我被骗了，这根本就不是一个枪战片，这片子太臭了，太闷了，但我每次都想，我要是不看了， 我就对不起我刚才浪费的时间，我就看完了， 结果还是个闷屁，三个多小时。
但是我里面学会了一句话，一句台词，也是一个娘们说的，我就把这个台词发给了我撩的那个女的，我发短信告诉她，我就像这个世界，这个世界是不会变的，来适应这个世界吧，哈哈哈哈哈。
我说，嗯，还挺文艺的，撩那些爱唱歌写东西的女的还行。

10号就是丁丁哥哥的一个劣质仿制品。相比于丁丁哥哥选择和这个世界谈谈，10号选择适应这个世界。于是他手里有一把“陆四式”手枪。

“陆四式”手枪比较老了，性能不好，10号没有理由特地选这个型号。
丁丁哥哥死于何事，想必不用再赘述了。

“我辈执笔文人，每觉我民族文化只是一大酱缸，肮脏污染之外，一无可取，果尔，则吾人对上述千千万万之烈士圣贤，又何以交代？正因为我民族中也多的是黄兴一类的贤人烈士，才能抵制那些民族败类、文化渣滓、昏君独夫、党棍官僚、土豪劣绅和市侩文痞，而使我民族文化绵延五千年而未至于绝代也。言念及此，每于午夜清晨，试溯旧史，辄至感慨万端，有时且垂涕停笔，不能自已。历史学家也是人嘛！虽尽量压抑人皆有之的情感，仍难期其入至善之境也。”
--唐德刚

读这部小说的时候，我感到一股莫名的压抑感，压抑的连悲伤都没有了。也许我想成为丁丁哥哥，做不成，最后在世界的压迫下，堕入了酱缸，哈哈哈哈哈。

从图论的讲法上看，就是先列出一个人(记为小A)的所有朋友的朋友，在寻找小A和这些人之间有多少长度为2的通路。将这些通路数排序，寻找最高的那几个就可以了。

所以我们的Map/Reduce的任务就是：找出所有人的十个Top“推荐好友”。

社会化网络的图一般都很简单。我们假设输入是按name排序的。

我们使用两轮Map/Reduce任务来完成这个操作。

第一轮MR任务

这个任务的目的是计算每一对距离是2的人之间的通路数。

• 在Map函数中，我们先将每对朋友做一个笛卡尔乘积，说的不大清楚，举个例子，比如
  1. "ricky" => ["jay", "john", "mitch"]

  那么结果就是

  1.  ["jay", "john"], ["jay", "mitch"], ["john", "mitch"]

  他们都是通过ricky牵线搭桥认识的。将已经是朋友的组合筛选掉，再排好序。传给Reducer。

• 在Reduce函数中, 相同的组合必定会传给Reducer。所以Reducer只要数好有几个相同的组合传给他就行了.

第二轮MR任务

这一轮的MR任务是为了列出每个人距离为2的好友，查出他们直接究竟有几条路径。

• 在Map函数中，我们将每一组数据重新排列，保证一个人信息落在一个reducer上
• 在Reduce函数中，只要将每个人的可能好友之间的路径数排个序就可以了.

Follower推荐
如果我想要做Follower推荐而不是好友推荐怎么办呢？
很简单。只要将第一步的MR任务改为求“Follow关系”和“Followed”关系的笛卡尔乘积就可以了。这里就不列伪码了。

参考地址：http://horicky.blogspot.com/

感觉Eclipse4.0对于Eclipse3.6。在功能上相当于Eclipse3.6对于Eclipse3.5，在Eclipse个上变化并不大。毕竟Eclipse的功能主要靠插件提供，而Eclipse只是给这些功能提供一个展现的舞台。

对 于Eclipse平台本身，将Web技术引入到Eclipse平台内部。Eclipse开发者可以使用Css,Javascript等Web技术来开发插 件。新的RCP可以是一个富客户端开发工具，可以将应用程序编译成Flex,Dojo(js),以及本地版本运行。不过RCP在eclipse3.5已经出现了。

接下来介绍一些Eclipse4.0的新特性。

Eclipse4.0项目主页 http://www.eclipse.org/eclipse4/

新版工作台

全局搜索框

更灵活的布局

您现在可以将功能面板和编辑器叠在一起了。例如，在一些情况下，您可以将功能面板和编辑器叠在一起，以提供更多的空间。

您不仅可以混合操作面板和编辑器，你还可以在编辑器区域分割一块给操作面板，然后最大化编辑器区域。整个工作空间都显示编辑器。

Eclipse开发者相关的功能

• 通用事件总线
• 用户界面模块化
• 简洁的模型结构
• 使用CSS来控制样式
• 更多

虽然这些内容对于使用Eclipse的人用处不大，但是对于平台本身影响还是很大的。

Facebook的数据规模使得很多传统的解决方案根本不适用，或者无法分解来处理。保持一个拥有5亿用户的系统一直稳定可靠的运行，并不是一件很容易的事情。这篇文章介绍了一下Facebook使用的软件。

Facebook的扩展性挑战

在我们讨论细节之前，这里有一些Facebook已经做的软件规模：

• Facebook有570000000000每月页面浏览量 （据Google Ad Planner）。
• Facebook的照片量比其他所有图片网站加起来还多（包括Flickr等网站）。
• 每个月超过30亿张照片被上传。
• Facebook的系统服务每秒处理120万张照片 。 这不包括CDN服务中处理的照片。
• 每月超过25亿条的内容 （状态更新，评论等）被共享。
• Facebook有超过30,000服务器 （这个数字是去年一年！）

Facebook扩展所依赖的软件

Facebook是在某些程度上说仍然是LAMP的站点，但它比普通的LAMP大得多，以纳入其他元素和很多服务，并修改现行的做法。

例如：

• Facebook的仍使用PHP，但它已经为它建立一个编译器，以便它可以分为本地代码打开了Web服务器，从而提高性能。
• Facebook的使用Linux，但他特别为网络吞吐量做了优化。
• Facebook的使用MySQL，但主要是作为一个Key-value的持久性存储，Jions和服务器逻辑操作在Web服务器上操作。因为在那里更容易执行。

还有是自编写的系统，如Haystack，一个高度可扩展的对象存储，用来存储Facebook的照片。还有Scribe，一个日志系统，可以运行在Facebook的巨大规模上的日志系统。

OK。现在 我们介绍一下全球最大的社会网络网站的所使用的软件吧。

Memcached

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

Facebook的每时每刻都有数10TB的数据缓存在Memcached的数千台服务器上。 它可能是世界上最大的Memcached的集群了。

HipHop for PHP

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

一个工程师小团队在Facebook（一开始只有三人）花了18个月时间开发HipHop，现在已经是可用状态。

Haystack

Haystack是Facebook的高性能照片存储/检索系统（严格来说，是一个对象存储，因此它并不一定要存储照片）。 它有许多工作要做;有超过200亿张上传的照片，并且每一个被保存在四个不同的分辨率，因此有超过800亿张照片。

它不仅是对能够处理的上亿的照片，运行表现也是至关重要的。 正如我们前面提到的，Facebook的服务约120万张照片每秒 ，这个数字不包括CDN上的。 这是一个惊人的数字。

BigPipe

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

例如，在聊天窗口是分开的，新闻Feed也是分开的，等等。 这些pagelets可以在一个页面表现的时候同时使用，这是该页面表现的时候获取进来的。即使某些工程的一部分关闭或中端，用户也可以获得一部分网页。

Cassandra

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

除了Facebook，还有一些人也用它，例如Digg的。 不过最近Twitter放弃了cassandra。

Scribe

Scribe是一个灵活的日志系统，Facebook在他的内部大量使用。 它的能够处理在Facebook的大规模日志记录，并自动处理新的日志记录类别,Facebook有数百个日志类别(categories)。

Hadoop and Hive

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

Hadoop和Hive是开源的（Apache项目），有为数众多的追随者，例如雅虎和Twitter。

Thrift

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

Facebook已经让Thrift开源。更多的语言支持已被添加到Thrift。

Varnish

Varnish是一个HTTP加速器，可以作为一个负载平衡器，并缓存的内容，然后可以以闪电般的速度送达。

Facebook使用的arnish来处理照片和个人资料图片，处理每天数十亿的要求。 和其他的东西一样，Varnish是开源的。

保持Facebook 顺畅运行的其他东西。

我们已经提到的软件，组成了Facebook的系统，并帮助运行在大规模上。 但是，处理这么大的系统是一个复杂的任务，因此我们将列出一些其他的东西，他们保持了Facebook的平稳运行。

渐进发布和暗启动

Facebook有一个他们所谓的守门人制度（Gatekeeper），允许他们可以给不同的用户运行两套不同的系统。 这让Facebook渐进的发布新的功能，A / B测试，只为Facebook雇员发布等的某些特性。

Gatekeeper也可以让Facebook实现“暗启动”，这是在用户使用一些功能之前，就激活某些功能（因为用户没有察觉，所以称之为暗启动）。 这将作为一个现实世界的压力测试，在正式启动前，帮助揭露一些功能障碍和其他问题。 暗启动通常是在正式启动前两个星期。

Profiling的直播系统

Facebook的仔细监控其系统，有趣的是它也负责监察每一个PHP函数在生产环境的性能。 检测各个PHP的环境的配置运行情况。使用开源工具，XHProf 。

渐进的利用关闭功能来提升性能

如果Facebook运行时出现性能问题，有一个办法，就是逐步禁用不太重要的功能，以增强Facebook的大量核心功能表现。

我们没有提及的事情

我们没有提到硬件相关的事情，但这也是提高可伸缩性的重要一环。例如，就像其他大型站点，Facebook利用CDN来处理静态内容。Facebook还有一个the huge data center，可以帮助他扩展更多的服务。

Facebook的开源情结

不仅是Facebook使用（和帮助），如Linux，Memcached的，MySQL和Hadoop的开源软件，以及许多其他情况下，也贡献许多了其内部开发的软件。

Facebook亦开源了Tornado，一个高性能的网络服务器框架，由FriendFeed团队开发。

关于开放源码软件清单，可以在Facebook’s Open Source page.找到。

Data sources:

http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/

Various presentations by Facebook engineers, as well as the always informativeFacebook engineering blog.