淘宝分布式文件系统存储引擎

本人的博客园网址
链接: link.
最近我在老师的带领下研究淘宝分布式文件系统存储引擎的源码。这也是我第一篇写在CSDN上的博客。
话不多说，直接切入正题。

淘宝为什么不适用普通的文件系统来存储海量小文件

1. 我们知道普通文件在查询的时候是这样的，首先先在硬盘的目录项区搜寻我们要找的文件的inode number，而后根据这个inode number去inode table（存储的是关于每个文件的信息，诸如文件数量大小之类）中取得对应的inode信息，最后根据inode信息来得到小文件所在块（块也就是文件存取的最小单位，常见的由八个扇区来组成一个块，扇区是硬盘存储数据的最小单位，512kb，通常块的大小为4kb）。如此多次的查找过程，带来的是磁盘多次的寻址换道，时间浪费，效率低下。
2. 另外，频繁的新增和删减，将会导致磁盘的碎片化，不同文件的存储所需要的磁盘空间不同，势必在删除文件的过程中导致有些空间无法及时地得到利用，降低了文件io的效率和磁盘的使用率。
3. 如果采用普通文件的存储方式，inode信息如果需要缓存，将会占用大量的内存。缓存效果不好。

分布式文件系统架构

基于以上原因，淘宝采用分布式文件系统存储引擎。
1.使用一个个block来进行存储小文件，每个block的大小为64MB，每个块都用一个唯一的整数对其进行标识。block的存储空间进行预先分配。
2.每个block文件都对应有一个index索引文件，index索引文件将会在服务启动的时候映射如内存，以此来增加文件操作的速度。
3.索引文件可分为两个部分，其一是索引头部信息（indexheader）里面存储的是关于对应块文件的主要信息，其二是存储的MetaInfo，许多的metainfo存储的关于存储在块文件里的小文件的基本信息，以便于我们对于小文件的存取。其中metainfo采用哈希链表进行组织。

为便于理解，上图。

可重用链表节点：当我们删除小文件信息时，为了避免不必要的移动，我们并不将其对应的metainfo删除，而是将其加入到可重用链表节点中，如此下一次插入小文件的时候，优先使用可重用链表节点中的节点。

BlockInfo结构

有一定数据结构基础的，不难理解整个分布式存储引擎的架构。

如有错误，望不吝赐教！