Facebook 海量数据处理

对着眼前黑色支撑的天空 /  我突然只有沉默了
我驾着最后一班船离开 / 才发现所有的灯塔都消失了
这是如此触目惊心的 / 因为失去了方向我已停止了
就象一个半山腰的攀登者 / 凭着那一点勇气和激情来到这儿
如此上下都不着地地喘息着 / 闭上眼睛疼痛的感觉溶化了
--达达乐队《黄金时代》

好几个地方看到这个 Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos,是 Facebook 的 Jason Sobel 做的一个 PPT,揭示了不少比较有参考价值的信息。【也别错过我过去的这篇Facebook 的PHP性能与扩展性

图片规模

作为世界上最大的 SNS 站点之一,Facebook 图片有多少? 65 亿张原始图片,每张图片存为 4-5 个不同尺寸,这样总计图片文件有 300 亿左右,总容量 540T,天! 峰值的时候每秒钟请求 47.5 万个图片 (当然多数通过 CDN) ,每周上传 1 亿张图片。

图片存储

前一段时间说 Facebook 服务器超过 10000 台,现在打开不止了吧,Facebook 融到的大把银子都用来买硬件了。图片是存储在 Netapp NAS上的,采用 NFS 方式。

图片写入

Facebook_write.png

尽管这么大的量,似乎图片写入并不是问题。如上图,是直接通过 NFS 写的。

图片读取

Facebook.png

CDN 和 Cachr 承担了大部分访问压力。尽管 Netapp 设备不便宜,但基本上不承担多大的访问压力,否则吃不消。CDN 针对 Profile 图象的命中率有 99.8%,普通图片也有 92% 的命中率。命中丢失的部分采由 Netapp 承担。

图中的 Cachr 这个组件,应该是用来消息通知(基于调整过的 evhttp的嘛),Memcached 作为后端存储。Web 图片服务器是 Lighttpd,用于 FHC (文件处理 Cache),后端也是 Memcached。Facebook 的 Memcached 服务器数量差不多世界上最大了,人家连 MYSQL 服务器还有两千台呢。

Haystacks –大海捞针

这么大的数据量如何进行索引? 如何快速定位文件? 这是通过 Haystacks 来做到的。Haystacks 是用户层抽象机制,简单的说就是把图片元数据的进行有效的存储管理。传统的方式可能是通过 DB 来做,Facebook 是通过文件系统来完成的。通过 GET / POST 进行读/写操作,应该说,这倒也是个比较有趣的思路,如果感兴趣的话,看一下 GET / POST 请求的方法或许能给我们点启发。

Facebook2.png

总体来看,Facebook 的图片处理还是采用成本偏高的方法来做的。技术含量貌似并不大。不清楚是否对图片作 Tweak,比如不影响图片质量的情况下减小图片尺寸。

EOF

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

招聘:创业团队找 PHPer

我们将基于千万级的用户群基础开发一个互联网网站平台,前所未有,不同以往,寻求开发高手加盟。

开发语言以 PHP 为主,数据库 MySQL,搜索用 Lucene 实现。

您将在以下环境下工作:

1、一个完全自行开发的高度定制 Full Stack PHP 框架,单一入口方式,全面支持分布式部署的多层架构方案。开发简单,安全高效;

2、开发环境与生产环境完全基于 Slackware Linux,软件版本更新与时俱进,高度定制编译优化,大致列举如下:

  • Nginx 0.7.3
  • PHP 5.2.6
  • MySQL 5.1.25
  • jQuery 1.2.6
  • Xcache 1.2.2
  • Memcached 1.2.5
  • ImageMagick 6.4.2-0
  • Varnish 2.0.0 tech preview 1
  • Lucene 2.3.2

等等,不再列举;

3、一个基于 Lucene 实现的可应付高并发请求的搜索框架,集成简单,伸缩性好。

4、高度注重对前端体验的优化,并在框架内实现了透明化的优化处理;

5、注重任何细节,为了减少 1ms 的程序执行时间,或者为了减少哪怕一个 http 请求,我们可以研究一整天,一直到认为最优化为止;

注:我们认为的典型页面请求的合理执行时间为 20ms 以内;

6、对框架和整体代码进行不断的 review,以理论上的的安全和高效执行的标准来严格要求,多一分不行,少一分也不可;

7、注重国内外技术趋势,乐于参加各种业内聚会。第一期上线后,我们也会总结我们的经验教训,与大家共分享。

目前进展

  • 1、第一期功能需求的开发工作即将完成,只要通过最终的代码检查和上线测试,即可上线;
  • 2、在整体框架下实现的前端体验,不需要任何特殊处理,任何页面均可达到 YSlow 的 95-99 分以上的评价;
  • 3、目前正在为各个功能的跨 PC、手持设备的浏览器页面自适应,绞尽脑汁中。

如果您想加入团队,您需要有以下资格:

  • 1、熟悉 Linux 下的 PHP5 + MySQL5 的开发,对面向对象、三层结构开发方式有深刻的理解;
  • 2、逻辑思维能力清晰,有良好的自我管理能力和团队工作心态,乐于沟通、分享和共同成长;
  • 3、有 XHTML+CSS+Javascript 前端能力者更佳。有 Java、C 或者开源软件开发经验者更佳。

如何认定资格?

  • 1、无任何学历限制,通过我们的面试即可。

薪酬待遇

  • 1、以斐波纳契数列中第六个数字为起点。

有兴趣者,请发您的简历与 zhanghe4(at)163.com 联系。

工作地点:北京东北三环。


以上是代朋友发的招聘信息(如果有笔误是我的事儿)。另外,杭州本地也在帮其它朋友找 PHPer ,有兴趣可以联系我。

Web 前端优化最佳实践之 Cookie 篇

Web 前端优化最佳实践第三部分面向 Cookie 。目前只有 2 条实践规则。

1. 缩小 Cookie (Reduce Cookie Size)

Cookie 是个很有趣的话题。根据 RFC 2109 的描述,每个客户端最多保持 300 个 Cookie,针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多,比如 Firefox 是 50 个) ,每个 Cookie 最多 4K,注意这里的 4K 根据不同的浏览器可能不是严格的 4096 。别扯远了,对于 Cookie 最重要的就是,尽量控制 Cookie 的大小,不要塞入一些无用的信息。

2. 针对 Web 组件使用域名无关性的 Cookie (Use Cookie-free Domains for Components)

这个话题在此前针对 Web 图片服务器的讨论中曾经提及。这里说的 Web 组件(Component),多指静态文件,比如图片 CSS 等,Yahoo! 的静态文件都在 yimg.com 上,客户端请求静态文件的时候,减少了 Cookie 的反复传输对主域名 (yahoo.com) 的影响。

从这篇 When the Cookie Crumbles 能看出,MySpace 和 eBay 的 Cookie 都不小的,想必是对用户行为比较关心。eBay 前不久构造了 Personalization Platform ,就是从 Cookie 的限制中跳出来。

延伸阅读:

EOF

Web 前端优化最佳实践之 Server 篇

Web 前端优化最佳实践第二部分面向 Server 。目前共计有 6 条实践规则。【注,这最多算技术笔记,查看最原始内容,还请访问:Exceptional Performance : Best Practices for Speeding Up Your Web Site

1. 使用 CDN (Use a Content Delivery Network)

国内 CDN 的普及还不够。不过我们有独特的电信、网通之间的问题,如果针对这个作优化,基本上也算能收到 CDN 或类似的效果吧(假装如此)。【Tin 说国内 CDN 用的挺多,看看 CDN 厂商的市场就知道了,还没走入寻常百姓家】

2. 添加 Expires 或 Cache-Control 信息头 (Add an Expires or a Cache-Control Header)

各个浏览器都有针对的方案, Apache 例子【注意:下面的说明例子还不够精细,具体的环境上还要加一些调整】:

ExpiresActive On
ExpiresByType image/gif "modification plus 1 weeks"

Lighttpd 启用 mod_expire 模块 后:

$HTTP["url"] =~ "\.(jpg|gif|png)$" {
expire.url = ( "" => "access 1 years" )
}

Nginx 例子参考:

location ~* \.(jpg|gif|png)$ {
if (-f $request_filename) {
expires      max;
break;
}
}

3. 压缩内容 (Gzip Components)

对于绝大多数站点,这都是必要的一步,能有效减轻网络流量压力。或许有人担心对 CPU 压缩对于 CPU 的影响,放心大胆的整吧,没事儿。Nginx 例子:

gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;

另外参见:

4. 设置 Etags (Configure ETags)

对于 Etag,可能是多数网站维护者都会忽略的地方。在这一系列优化规则出现之前,可能互联网上绝大多数站点都对这个问题忽略了。当然,Etag 对多数站点性能的影响并不是很大。除非是面向 RSS 的网站。【看到有朋友批评说写的简略,并且说 IE 不支持 ETag。明确说一下:IE 支持 ETag,倒是使用 IIS 要注意相关 Etag Bug。】

补充:我的意思是”很多网站在不注意的情况下都是打开 Etag 的,而没有网站关心如何用,消耗资源而不知。并不是说 Etag 不好,合理利用 Etag ,绝对能取得很好的收益.

5. 尽早刷新 Buffer (Flush the Buffer Early)

对这一条,琢磨了半天,貌似还是异步的思路。能更好的提升用户体验?

6. 对 AJAX 请求使用 GET 方法 (Use GET for AJAX Requests)

XMLHttpRequest POST 要两步,而 GET 只需要一步。但要注意的是在 IE 上 GET 最大能处理的 URL 长度是 2K。

前一篇:

下一篇分析一下 Cookie 。

EOF

Updated: 另请参见楼下高春辉的留言,很精彩