淘宝的图片存储架构

On 2010年08月31日, in highscalability, by netoearth

解决海量并发小文件的系统噩梦
LVS创始人,淘宝网技术委员会主席,淘宝网核心工程师章文嵩先生

淘宝网整体流量中,图片的访问流量要占到90%以上。淘宝整体图片存储系统容量1800TB(1.8PB),已经占用空间990TB(约1PB)。保存的图片文件数量达到286亿多个,这些图片文件包括根据原图生成的缩略图。平均图片大小是17.45K;8K以下图片占图片数总量的61%,占存储容量的11%。淘宝网之前一直采用的商用存储系统,应用NetApp公司的文件存储系统。随着淘宝网的图片文件数量以每年2倍(即原来3倍)的速度增长,淘宝网后端 NetApp公司的存储系统也从低端到高端不断迁移,直至2006年,即时是NetApp公司最高端的产品也不能满足淘宝网存储的要求。

架构自底向上,基本是:

底层的 TFS:taobao file system,是用来存储用户上传的原图的。基本是仿照gfs来做,有中心master(称为name server)来记录映射关系,其他的chunk server做实际存储。但是淘宝做了两个小trick的东西:1、不支持文件目录结构,只需要单层哈希即可。2、block和file id记录在文件名里面,加速查询。所以据称name server只需要消耗200m的内存,跑的很轻松。这个TFS似乎是专门为了图片服务做的(可能淘宝也没有其他地方需要大存储了),图片去重是做在 TFS里面。另外说下,TFS的造价大约在2kw左右,存储量在1.8P。用的是SATA硬盘并且没有做raid。省钱啊。

image server是用来生产缩略图的。据他们介绍,他们对缩略图的需要竟然有20多种规格,所以用时间换空间,实时计算。完全靠这一层image server来处理。他们调研过,graphmagick比ImageMagick性能要好。想想我们这边,可能很多时候就会打前端js的脑筋了。所以性 能才上不去。

两层cache的思路比较有意思,L1是cache计算好的缩略图,L2是cache被调用的原图。估计他们的同一张原图产出的多张缩略图,会比较容易相邻出现。另外,他们的cache策略,是基于FIFO而不是LRU,据说是减少写盘操作,这一节没太想明白。

他们的前端部署了CDN,目前全国22个节点。感觉他们的思路也比较有意思,整套系统,从最前端的CDN到最后端的TFS,都是由同一群人来做,系统得以统一考虑。我们这边是分开了两拨人去做,各有各的得失吧。

另外不得不佩服一下淘宝的开源精神,TFS在9月份将会开源。

章文嵩博士是淘宝网的研究员,主要负责基础核心软件研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本淘宝电子商务基 础设施。他也是开放源码及Linux内核的开发者,著名的Linux集群项目–LVS (Linux Virtual Server)的创始人和主要开发人员,LVS集群代码已在Linux 2.4和2.6的官方内核中。在设计和架构大型系统、系统软件开发、Linux操作系统、系统安全和软件开发管理上有着丰富的经验。他一直在自由软件的开发上花费时间,并以此为乐。

Comments are closed.