Facebook图片管理架构

　　Facebook的照片分享很受欢迎，迄今，Facebook用户已经上传了150亿张照片，加上缩略图，总容量超过1。5PB，而每周新增的照片为2亿2000万张，约25TB，高峰期，Facebook每秒处理55万张照片，这些数字让如何管理这些数据成为一个巨大的挑战。本文由Facebook工程师撰写，讲述了他们是如何管理这些照片的。
　　旧的NFS照片架构
　　老的照片系统架构分以下几个层：
　　上传层接收用户上传的照片并保存在NFS存储层。
　　照片服务层接收HTTP请求并从NFS存储层输出照片。
　　NFS存储层建立在商业存储系统之上。
　　因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了NFS存储层的缓存上限，导致每次招聘请求会上传都包含多次IO操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么Facebook主要依赖CDN的原因。为了解决这些问题，他们做了两项优化：
　　Cachr：一个缓存服务器，缓存Facebook的小尺寸用户资料照片。
　　NFS文件句柄缓存：部署在照片输出层，以降低NFS存储层的元数据开销。
　　新的Haystack照片架构
　　新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于HTTP的照片服务器上，照片存储在一个叫做haystack的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，IO操作只针对真正的照片数据（而不是文件系统元数据）。haystack可以细分为以下几个功能层：
　　HTTP服务器
　　照片存储
　　Haystack对象存储
　　文件系统
　　存储空间
　　存储
　　Haystack部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：
　　两个4核CPU
　　16GB32GB内存
　　硬件RAID，含256512MNVRAM高速缓存
　　超过12个1TBSATA硬盘
　　每个刀片服务器提供大约10TB的存储能力，使用了硬件RAID6，RAID6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决，硬盘缓存被禁用以防止断电损失。
　　文件系统
　　Haystack对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置，目前使用的文件系统为XFS。
　　Haystack对象库
　　Haystack是一个简单的日志结构，存储着其内部数据对象的指针。一个Haystack包括两个文件，包括指针和索引文件：
　　Haystack对象存储结构
　　指针和索引文件结构
　　Haystack写操作
　　Haystack写操作同步将指针追加到haystack存储文件，当指针积累到一定程度，就会生成索引写到索引文件。为了降低硬件故障带来的损失，索引文件还会定期写道存储空间中。
　　Haystack读操作
　　传到haystack读操作的参数包括指针的偏移量，key，代用Key，Cookie以及数据尺寸。Haystack于是根据数据尺寸从文件中读取整个指针。
　　Haystack删除操作
　　删除比较简单，只是在Haystack存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。
　　照片存储服务器
　　照片存储服务器负责接受HTTP请求，并转换成相应的Haystack操作。为了降低IO操作，该服务器维护着全部Haystack中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。
　　对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图拥有相同的随机Cookie和ID，图片尺寸描述（大，中，小，缩略图）被存在代用key中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到haystack中。
　　每张图片的索引缓存包含以下数据
　　Haystack使用Google的开源sparsehashdata结构以保证内存中的索引缓存尽可能小。
　　照片存储的写修改操作
　　写操作将照片数据写到Haystack存储并更新内存中的索引。如果索引中已经包含相同的Key，说明是修改操作。
　　照片存储的读操作
　　传递到Haystack的参数包括HaystackID，照片的Key，尺寸以及Cookie，服务器从缓存中查找并到Haystack中读取真正的数据。
　　照片存储的删除操作
　　通知Haystack执行删除操作之后，内存中的索引缓存会被更新，将便宜量设置为0，表示照片已被删除。
　　重新捆扎
　　重新捆扎会复制并建立新的Haystack，期间，略过那些已经删除的照片的数据，并重新建立内存中的索引缓存。