深入理解web开发中海量小文件带来的的危害及解决方案
本文为原创内容,转载请注明出处 ,谢谢
引言
试想一个电商项目中,允许每一个商铺拥有自己独立的前端设计,那么在店铺装修过程中每个店铺都会生成大量的静态文件(图片、css样式表、js脚本)。并且每个店铺会不断更新自己的商品,每上架一个商品也会产生新的静态文件,但就图片来说,每个商品少则5到10张多则几十张。另外,通常为了方便项目的组织与规划,适用于不同用途的样式表与脚本会分离出来形成不同的css文件和js文件,这就导致了这两种问价可能会非常小,有的可能只有几百Byte。像淘宝这样的巨型电商项目,这种小文件恐怕早已达到千亿级别的数据量了,那么如此之多的小文件到底会带来怎样的危害呢?
谈谈危害
-
从文件系统说起
打开计算机,在任意位置新建一个文本文件,从键盘随意输入一个字符。这个文本文件的大小理应为一个字节即1Byte,但是它占用的空间却是4KB。这是因为文件是存储在磁盘上的,磁盘的最小存储单位是扇区,一个扇区可以存储512Byte数据,操作系统读取硬盘时,由于一次读一个扇区效率过低,于是会一次性连续读入多个扇区,多个扇区组成一个“块”,即文件系统存取的最小单位。最常见的就是8个扇区,4KB大小。由此可见,即使是小于4KB的文件,其所占用的空间依然是4KB。这使得每有一个这样的文件存在于文件系统中时,就会产生造成一定的存储空间浪费。当然了,即使是大文件,例如一个4095KB大小的文件,它的占用空间也必须是4KB的倍数,也即4MB。也就是说,大文件的存储,由于操作系统的设计原因,每个文件也会产生一个内部碎片,这个碎片小于4KB,为存储一个大文件而牺牲这么一点空间显然是值得的。而对于小文件,尤其是数量到达一定程度的小文件,若其平均大小只有3KB,那么百万数量级的这种小文件就会产生GB大小级别的内部碎片,十亿数量级的这种小文件就会产生TB级别的内部碎片。像淘宝这样的巨型电商项目若仍直接去存储这样的小文件,将会造成大量的空间浪费。
-
说说inode
文件存储在磁盘上时,文件系统同时会生成一个存储文件元信息的inode。这些元信息包括但不限于文件的大小,文件的创建者,文件的创建日期以及文件的读写权限等。那么理所当然的,存储这些inode也是会消耗磁盘的空间的。在Linux中,有专门的一个区域用于存放inode,因此,inode是有限的。试想,当有成千上万的小文件存在于服务器的文件系统当中时,最先消耗完的肯定不是磁盘的空间,而是inode,这就会导致大量的空闲空间无法使用。(深入了解inode可查看这篇大佬的博客)