新浪微博图床架构解析

可以先看一下  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