本地文件系统的实现方案LocalFileSystem
适用场景：用于存储网站的图片和生成的静态化页面，适用于小型网站，只有几个java类就实现了，内嵌在网站程序中，是低技术成本的存储方案。无意与FastDFS、TFS、OSS、Ceph等等分布式文件系统竞争。
目录结构：20/99/99/5709f0ba31e342bda28d03485b257c94.jpg
3层目录结构：一层目录00-19，二层目录00-99，三层目录00-99，
一层目录00-19，要控在较少的数量，方便运维人员使用NFS把某个目录放在远程服务器。若是有256个一级目录太多了，运维人员做NFS时工作量太大。
二三层目录00-99，我以前用过FastDFS,它使用00~FF的256个目录，我常常查bug时要找某个文件，字母的文件名并不方便我人工查找。还是有序的数字方便。
单目录下最大文件数量：第三层目录每个目录下计划最多放1000个文件，超过这个数量由于操作系统的文件的原理，IO性能会下降。
文件名：使用UUID，有点长，还可忍受。主要生成方便技术成本低。
可存储的文件数量：20个目录*100个目录*100个目录*1000个文件=2亿个文件，理论上可存储2亿个文件，这对于“小型网站”来说太够用了。
总大小：按一个文件平均 70K，2亿个文件，总体积是13TB。 “小型网站”也达不到这个体积。
扩容与分布式的解决方案：使用NFS，最多可把20个目录 用NFS存储到远程服务器，最多可使用20块硬盘，扩展了存储容量，实现了人工的低水平的低成本的分布式，由于磁盘数量多了提高了总体的IO性能。例如 1.5万转的快盘小文件随机iops一般在150左右，磁盘是瓶颈，NFS网络传输不会成本瓶颈。
文件的备份方案：依靠linux操作系统的文件同步技术来实现备份，如 rsync。本存储服务不解决备份问题。我以前做过由Java程序来负责同步备份的同类程序，效果不好，因复杂的网络原因、源与备件之间文件数量对不上，备份的可靠性低。把事情做简单，以至于明显没有bug。
本实现方案的特点：本方案各方面做的都很“均衡”。定位目标低、追求简单实用，开发成本低、学习成本低、运维成本低、可满足业务系统对小文件存储的要求。有一定的扩展能力，在使用NFS后单盘容量、单盘IO、网络吞吐量等方面指标都很“均衡”。
性能：考量小文件存储的主要性能指标是IOPS，瓶颈在于磁盘， 1.5万转的SAS盘小文件随机iops一般在150左右，1万转的盘小文件随机iops一般在100左右，7200转的STAT盘小文件随机iops一般在70左右。这是硬件在这种应用场景下自身的性能，无法超越。本程序性能不是瓶颈，NFS网络传输性能不是瓶颈。如果你采用一块1.5万转的SAS盘，每秒可读150次。如果你采用10块1.5万转的SAS盘，每秒可读1500次。本程序不提供缓存能力，这里不考虑缓存对性能的提升。
Tomcat集群环境下的图片文件
背景
tomcat集群环境下，tomcat部署了多个节点，每个tomcat中都有用户上传的图片。导致以下问题。
- 问题一，项目上线时会覆盖线上的由用户上传的图片。（非集群环境就有此问题）
- 问题二，用户上传一张图片，这张图片，只会保存一个tomcat节点中，其它tomcat节点无图。
问题一的解决
解决：可配置图片存储在外部路径。
把图片放置在tomcat之外的一个集中共享的目录中，项目上线时不会发生覆盖。
修改配置文件：/shop-data/src/main/resources/fdp.properties
问题二的解决
把图片放在tomcat以外的文件夹中，再通过NFS共享给其它tomcat节点，用户上传图片都集中写到一个点，所有tomcat都可以读到同一份图片文件。