Facebook兆级别图片存储及每秒百万级别图片查询原理

前言

Facebook(后面简称fb)是世界最大的社交平台,需要存储的数据时刻都在剧增(占比最大为图片,每天存储约20亿张,大概是微信的三倍)。

那么问题来了,fb是如何存储兆级别的图片?并且又是如何处理每秒百万级别的图片查询?

本文以简单易懂,图文并茂的方式来解释其中的原理,并不涉及空洞,难解的框架,也没有大篇章的废话铺陈,只有痛点与反思;就如同fb的架构师所说:fb的存储架构就像高速公路上换轮胎,没有最完美的设计,我们最求的只是如何让它变得更简单。

短篇介绍

fb的图片存储系统叫做HayStack,目前已存储超过120PB的数据,用户每天会上传20亿张图片。fb图片搜索峰值,需要提供每秒100-200万张的图片搜索。这些数据还再不断地增加。

稍微分析下用户使用场景,图片写入一次,频繁读取,从不修改,很少删除。传统的文件系统:每个图片都会有一些元数据,在我们的需求中,这些信息无用,且浪费存储空间,更大的性能消耗是文件的元数据需要从磁盘读到内存中来定位图片位置,在fb的量级上,元数据的吞吐量便是一个巨大的瓶颈。

高吞吐量,低延迟是HayStack所追求的,所以HayStack希望每个图片读取操作至多需要一个磁盘,并且减少每个图片的必要元数据,并将它们保存至内存中。为了做好容灾,HayStack会将图片复制多张并保存至不通数据中心,以确保不反回404,error给客户。

典型的设计方案

上图为典型的设计方案:

1.用户通过浏览器发送图片信息请求至web server;2.web server 构造一个url,引导浏览器到对应位置下载图片;3.通常这个url指向一个CDN,如果CDN有缓存相关图片的话,它会将图片立刻返回给浏览器;4.否则,会解析url,并在Photo Storage中找到对应的图片;5.6.返回给用户。

NAS-NFS

在fb的服务中,只有CDN不足以解决全部需求,对于新图片,热门图片CDN确实很高效。但是对于一些个人上传的老图片请求,CDN基本上会全部命中失败,又没有办法将图片全部缓存起来。所以这里,可以采用NAS-NFS来解决问题。

基本操作与上面相同,5.6.photo store server 解析url得出完整的卷和路径信息,在NFS上读取数据,然后返回给CDN。

这种设计的瓶颈:NFS卷的每个目录下存储上千张图片,导致读取时产生了过多的磁盘操作。

HayStack

HayStack架构包含3个核心组件:HayStack Store,HayStack Directory和HayStack Cache。 Store是存储系统,负责管理图片的元数据。不同机器上的物理卷对应一个逻辑卷,HayStack将一个图片保存至一个逻辑卷时,那么图片便对应写入所有物理卷。Directory 维护了逻辑到物理卷的映射以及相应的元数据,例如说,某张图片保存在哪个物理卷里,某个物理卷的存储空间等。Cache的功能,类似内部的CDN,它帮Store挡住热门搜索。


上图描述了3个核心组件的相互作用。在HayStack架构中,浏览器的请求被引导至CDN中(或Cache上),Cache本质就是CDN,为了避免冲突,我们使用CDN来表示外部系统,使用Cache表示内部系统。

1.当用户发出请求给web server,2.web server 使用Directory来构建图片的url,3.4.5.6.7.8.9.10.url包含一段信息,如下:

http(s)://CDN/Cache/machine_id/volume_ID_Photo

一目了然,url包含CDN地址信息,Cache信息,以及保存图片的物理卷ID,以及图片信息。

图4,位用户上传图片的流程,1.用户发送请求至web server;2.web server请求Directory一个可用的逻辑卷,物理卷,并将图片信息记录下;3.将相关信息发送至web server;4.web server将图片上传至Store;5.返回成功信息。

Directory

主要有4个功能:

1.它提供了逻辑卷到物理卷的映射,web服务器上传或读取图片时需要使用这个映射。

2.它在分配写请求,读请求到物理卷时,需保证负载均衡。

3.它决定一个图片的请求,是发送至CDN或Cache,这个决定可以动态调整是否依赖CDN。

4.它指定哪些卷是只读的。

当我们增加Store的时候,那些卷都是可写的,可写的机器会收到上传信息。当它们到达容量上限时,标记它们为只读。

Cache

Cache的实现可以理解为一个分布式Hash Table,以图片ID为key,定位缓存的图片数据。如果Cache未命中,那么Cache则根据URL到指定的Store中,读取图片数据。

Store

很简单,根据提供的一些元数据信息,包括图片ID,逻辑卷ID,物理卷ID,找到对应的图片,未找到则返回错误信息。

下面简单描述一下物理卷与映射的结构,一个物理卷可以理解为一个大型文件,包含一系列的needle,每个needle就是一张图片。如下图所示。

为了快速索引needle,Store需要为每个卷提供一个内存中的key-value映射。

HayStack文件系统

HayStack可以理解成基于Unix文件系统搭建的对象存储架构。Store使用的文件系统是XFS,XFS有两个优点,首先,XFS中的临近大型文件的blockmap很小,可放入内存存储。再者,XFS提供高效的文件预分配,减少磁盘碎片问题。使用XFS,可以完全避免检索文件系统导致的磁盘操作。

文末也给大家,分享主要有C/C++,Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK技术,面试技巧方面的资料技术讨论。

感兴趣的朋友可以加群:812855908

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,377评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,390评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,967评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,344评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,441评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,492评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,497评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,274评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,732评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,008评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,184评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,837评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,520评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,156评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,407评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,056评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,074评论 2 352

推荐阅读更多精彩内容