深入理解web开发中海量小文件带来的的危害及解决方案

深入理解web开发中海量小文件带来的的危害及解决方案

本文为原创内容，转载请注明出处 ，谢谢

引言

试想一个电商项目中，允许每一个商铺拥有自己独立的前端设计，那么在店铺装修过程中每个店铺都会生成大量的静态文件（图片、css样式表、js脚本）。并且每个店铺会不断更新自己的商品，每上架一个商品也会产生新的静态文件，但就图片来说，每个商品少则5到10张多则几十张。另外，通常为了方便项目的组织与规划，适用于不同用途的样式表与脚本会分离出来形成不同的css文件和js文件，这就导致了这两种问价可能会非常小，有的可能只有几百Byte。像淘宝这样的巨型电商项目，这种小文件恐怕早已达到千亿级别的数据量了，那么如此之多的小文件到底会带来怎样的危害呢？

谈谈危害

1. 从文件系统说起

   打开计算机，在任意位置新建一个文本文件，从键盘随意输入一个字符。这个文本文件的大小理应为一个字节即1Byte，但是它占用的空间却是4KB。这是因为文件是存储在磁盘上的，磁盘的最小存储单位是扇区，一个扇区可以存储512Byte数据，操作系统读取硬盘时，由于一次读一个扇区效率过低，于是会一次性连续读入多个扇区，多个扇区组成一个“块”，即文件系统存取的最小单位。最常见的就是8个扇区，4KB大小。由此可见，即使是小于4KB的文件，其所占用的空间依然是4KB。这使得每有一个这样的文件存在于文件系统中时，就会产生造成一定的存储空间浪费。当然了，即使是大文件，例如一个4095KB大小的文件，它的占用空间也必须是4KB的倍数，也即4MB。也就是说，大文件的存储，由于操作系统的设计原因，每个文件也会产生一个内部碎片，这个碎片小于4KB，为存储一个大文件而牺牲这么一点空间显然是值得的。而对于小文件，尤其是数量到达一定程度的小文件，若其平均大小只有3KB，那么百万数量级的这种小文件就会产生GB大小级别的内部碎片，十亿数量级的这种小文件就会产生TB级别的内部碎片。像淘宝这样的巨型电商项目若仍直接去存储这样的小文件，将会造成大量的空间浪费。

2. 说说inode

   文件存储在磁盘上时，文件系统同时会生成一个存储文件元信息的inode。这些元信息包括但不限于文件的大小，文件的创建者，文件的创建日期以及文件的读写权限等。那么理所当然的，存储这些inode也是会消耗磁盘的空间的。在Linux中，有专门的一个区域用于存放inode，因此，inode是有限的。试想，当有成千上万的小文件存在于服务器的文件系统当中时，最先消耗完的肯定不是磁盘的空间，而是inode，这就会导致大量的空闲空间无法使用。（深入了解inode可查看这篇大佬的博客）