新浪微博图床架构解析

标签: 新浪微博 图床 架构 | 发表时间:2014-03-06 18:05 | 作者:zxcvg
出处:http://blog.csdn.net

可以先看一下  http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw 新浪微博官方发出来的文章。以下我们来解析一下如何构建高可用的图片存储系统 以满足现在日益增长的图片量,保证系统稳定高效的运行。

 

微博图床系统分析

 

图床系统 ,我们先来分析下基于此类系统的一个特性

特性:

  1. 1.       小文件数量巨多,通常为几十k到几百k不等。

                                       i.              通常我们认为大小在1MB以内的文件称为小文件,百万级数量及以上称为海量,由此量化定义海量小文件问题 称为LOSF

  1. 2.       频繁的读写操作
  2. 3.       大规模的图片处理

基本上可以简单的描述为 在图片数量巨大且读写操作频繁的时候,图片的upload或者download出现了高延时,严重影响了用户的使用 更有甚者 导致服务器崩溃。

 

造成这些现象的主要原因是什么 呢?

 

先来了解一下传统的图片存储架构

 

 

依靠cdn来解决图片访问问题,同时尽量使之在缓存中命中

采用负载均衡

         负载均衡(Load Balance)将大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间提高处理能力,负载均衡建立在现有网络结构之上,它提供了一种廉价、有效、透明的方法,来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

尤其是全局负载均衡,能大大提高用户的访问速度

把各地的用户对于资源的访问,根据内容有无,服务器负载,网络带宽和速度,将请求导向到不同的服务器集群进行服务。

在用户量和性能需求的情况下,只能添加高端的设备。

 

这样的存储架构在图片日益增多的情况下,会产生如下的问题:

  1. 1.       从设计上看,扩展性差,成本过高,很难满足容灾需求。

从硬件及软件角度看:衡量存储系统的标准:IOPS和数据吞吐量 (单位时间内成功传输的数据)

  1. 2.       缓存数据量大
  2. 3.       大量的磁盘寻址
  3. 4.       大量的元数据操作
  4. 5.       单个目录的文件数限制
  5. 6.       网络开销大

 

缓存数据量大:增加服务器时间长 ,重启服务器时间长。

缓存中一般为热点文件,在数据量巨大的时候缓存命中率会下降,从而导致会频繁的从文件服务器查找并下载文件。

 

大量的磁盘寻址:影响磁盘的关键因素是磁盘I/O服务时间,即磁盘完成一个I/O请求所花费的时间,它由寻道时间、旋转延迟和数据传输时间三部分构成。因此可以计算磁盘的IOPS= 1000 ms/ (Tseek + Troatation + Ttransfer),如果忽略数据传输时间,理论上可以计算出磁盘的最大IOPS。当I/O访问模式为随机读写时,寻道时间和旋转延迟相对于顺序读写要明显增加,磁盘IOPS远小于理论上最大值。定义有效工作时间Pt=磁盘传输时间/磁盘I/O服务时间,由此可知随机读写单个文件效率要低于连续读写多个文件。

大量的元数据操作:当小文件数量急剧增加时,对大量元数据的操作会严重影响系统的性能。

单个目录文件数:以磁盘为存储介质的单机文件系统(如ext4、xfs等),文件都是以目录树结构来组织的,当文件数很多时,目录内的文件数会很多、目录层次也会变深,索引时间长,一次路径名查找可能需要多次磁盘IO,并且单机无法存储。

网络开销增大:增加了RPC网络通信开销,扩大了小文件访问延时 。

 

问题分析出来了 那么如何解决呢?

先了解下现在各大互联网公司的解决方案:

淘宝的TFS

         TFS(Taobao File System)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统,主要针对海量的非结构化数据,它构筑在普通的Linux机器集群上,可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储,通常文件大小不超过1M,满足了淘宝对小文件存储的需求,被广泛地应用 在淘宝各项应用中。

Facebook Haystacks

Haystack,一个为高效存储和检索billion级别图片而优化定制的对象存储系统。

微博 notfs  

新浪自主研发的notfs用户态小文件存储系统,以解决传统文件系统目录索引查询带来的额外的磁盘IO开销,吞吐是传统方案的3倍,并能获得一致的常量低延迟访问。

Twitter Blobstore

Blobstore是由Twitter开发的一个低成本和可扩展的的存储系统,可以用来存储图片以及其他的二进制对象(称为“blob”)。在开始构建Blobstore时,Twitter有三个设计目标:

低成本:可以大大减少花费在添加图片到Tweet中的时间和成本。

高性能:图片延迟保持在几十毫秒之内,同时保证每秒上千万张吞吐量的图片请求。

易于操作:随着Twitter基础设施的不断增长,能够扩展操作开销。

 

解决上述问题 我们需要优化或者说是解决以下的点:

架构上:采用分布式存储架构

硬件优化:使用速度更快的SSD作为全部或部分存储介质,采用处理能力更强或更多的CPU,配置更大的内存,采用延迟更小、带宽更高的网络设备优化网络传输效率等等。

         优点是最行之有效也是做简单的做法。

                    缺点是成本过大,高高高富帅公司。

元数据优化:在文件命中蕴含部分或全部的元数据信息,减少对元数据的访问同时有效的减少目录的深度 减少的I/O操作,在添加Cache系统对元数据缓存,采用hash等高效的数据结构。

小文件合并存储:此类问题的主要解决方案,

         它通过多个逻辑文件共享同一个物理文件,将多个小文件合并存储到一个大文件中,实现高效的小文件存储

         首先,减少了大量元数据。通过将大量的小文件存储到一个大文件中,从而把大量的小文件数据变成大文件数据,减少了文件数量,从而减少了元数据服务中的元数据数量,提高了元数据的检索和查询效率,降低了文件读写的I /O操作延时,节省了大量的数据传输时间。

其次,增加了数据局部性,提高了存储效率。磁盘文件系统或者分布式文件系统中,文件的元数据和数据存储在不同位置。采用合并存储机制后,小文件的元数据和数据可以一并连续存储大文件中,这大大增强了单个小文件内部的数据局部性。小文件合并过程中,可以利用文件之间的空间局部性、时间局部性以及关联,尽量将可能连续访问的小文件在大文件中进行连续存储,增强了小文件之间的数据局部性。这直接降低了磁盘上随机I/O比率,转换成了顺序I/O,能够有效提高I/O读写性能。另外,小文件单独存储会形成外部和内部碎片,而合并存储后存储碎片将大大降低,这极大提高了LOSF存储效率。

再次,简化了I/O访问流程。

 

此外还要解决容灾,负载,扩容等实际问题。

  像微博的图床系统就采用的跨IDC的分布式存储系统

微博图床平台是一个跨IDC的大规模分布式对象存储系统,也是新浪第一个实现跨IDC多主写入容灾,以实现全网服务可用性的技术平台。跨IDC多主写入意味着任意一个数据中心故障,就可以快速切换容灾至其他可用数据中心。我们使用了一种内部叫做BOR的基于业务对象的复制协议,内部的最终一致性与实时代理结合,以实现用户端的强一致性。

 

淘宝是多机房容灾 原理都差不多。

 

小文件的存储解决之后,对于图床系统最后一个需要解决的问题就是压缩。

 

图片压缩的过程是一个CPU和内存消耗性的耗时逻辑

 

微博的解决方案 微博发出的文章中有

http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw

淘宝的解决方案 是在下载环节来进行压缩图片

 

部署imageServer集群,做图片压缩处理

若请求图片在Cache中,直接发送;Cache未命中,本地有原图根据本地原图处理并缓存;本地无,则从TFS取得原图 处理并缓存。

 

淘宝实时生成缩略图的好处:一是节省后端存储 减轻压力 二是可以随时生成 动态灵活。

 

分析到此结束,当然怎么应用到自家的系统中 还需要根据自己的系统来定制什么需要什么不需要。

 谢谢!

文章 参考了 一些小文件存储的博文,其中也引用了些内容  http://blog.csdn.net/liuaigui/article/details/9981135

作者:zxcvg 发表于2014-3-6 10:05:53 原文链接
阅读:80 评论:0 查看评论

相关 [新浪微博 图床 架构] 推荐:

新浪微博图床架构解析

- - CSDN博客架构设计推荐文章
可以先看一下  http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw 新浪微博官方发出来的文章. 以下我们来解析一下如何构建高可用的图片存储系统 以满足现在日益增长的图片量,保证系统稳定高效的运行. 图床系统 ,我们先来分析下基于此类系统的一个特性.

新浪微博技术架构分析-转载

- 盛开 - 人月神话的BLOG
中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展. 图为微博平台首席架构师杨卫华演讲. 大家下午好,在座的大部分都是技术开发者,技术开发者往往对微博这个产品非常关心.

[转]新浪微博的架构发展历程

- - 小彰
新浪科技讯 11月16日下午消息,由 新浪微博( http://t.sina.com.cn)( http://t.sina.com.cn)主办的中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴. 作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展.

亿级用户下的新浪微博平台架构

- - 博客园_知识库
  新浪微博在2014年3月公布的月活跃用户(MAU)已经达到1.43亿,2014年新年第一分钟发送的微博达808298条,如此巨大的用户规模和业务量,需要高可用(HA)、高并发访问、低延时的强大后台系统支撑.   微博平台第一代架构为LAMP架构,数据库使用的是MyIsam,后台用的是php,缓存为Memcache.

新浪微博混合云架构实践挑战之容器编排设计与实践

- - IT瘾-tuicool
《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践. 本文是该系列的第五篇,主要介绍容器编排的设计与实现. 《微博混合云架构》专栏主要包括以下8篇内容:. DCP的容器编排设计与实践. 最近由于个人原因,与InfoQ约稿的专栏《微博混合云架构》很久没更新了,在此深表歉意.

围攻新浪微博

- Jos - 望月的博客
在国内的门户微博中,新浪微博无疑是目前用户数量最多、媒体属性最强的,但是,最近,却连续看到一些互联网的知名人士高调宣布退出或者关闭新浪微博的博文,使用和不使用某个产品本就是个人的自由,但如此高调的宣布,并进行口诛笔伐,就值得关注了. 本文试图通过分析谷奥事件,宋石男和贾葭两位老师离开新浪微博的事件分析新浪微博的是与非.

新浪微博连接 2.3

- leeking001 - 我爱水煮鱼
新浪微博连接是我使用新浪微博 API 接口开发的一个 WordPress 插件,它的主要功能是能让用户使用新浪微博账号登陆 WordPress 博客,并且可以直接使用新浪微博的头像,同步博客日志到 WordPress 博客. 经过几天的测试,新浪微博连接插件升级到 2.3,主要修正:同步博客到新浪微博的问题,并且同步内容更为丰富,规则改为:【日志标题】+ 日志内容摘要 + 日志链接.

新浪微博n大傻

- suki - broom's blog
看不到follow的人之间的交互这类产品本身的问题就不提了,就说说用户行为的傻. 其中有些行为也是产品本身纵容的. 三天两头换id的,搞个巨长的id既占字数又让别人压根没法手动@的,带个公司前缀的,用流行语的. 完全没有网络时代id就是个人身份的概念,意识还停留在QQ时代,以为随便改昵称呢. 某些专门发垃圾小段子的帐号尤甚.

V5后的新浪微博

- - It Talks--上海魏武挥的博客
正是在这个内外交困的时刻,新浪微博展开了它的商业化之旅,前途如何,尚未可知. 近日新浪微博发布了它的第五个版本,称为“V5”,在这个版本中,一个很明显的变化是:它长的有点像Facebook,用户不仅可以设置较大的头像,也可以在顶部自定义一张大图. V5版本的一些细节做得很用心,无论是提示语,还是版式的细微之处.

新浪微博不是Twitter

- 马克叔叔 - 月光博客
  Twitter是互联网短信,新浪微博以微博客Twitter式弱关系切入,正在转型SNS. 转型的挑战在于:1.如何融合弱关系和强关系. 2.如何用弱关系倒逼中国社会的强关系和潜关系.   国内有一些Twitter的拥趸,认为微博抄Twitter都抄不到点子上.   “Twitter 是四两拨千斤的艺术.