文件系统管理与可视化模块开发-Part1

链接是链接到自己的博客中的，等审核通过了在改到掘金 文章系列:

1. 文件系统管理与可视化模块开发-Part1
2. 文件系统管理与可视化模块开发-Part2

最近学了node之后，一直想玩一些花样，之前开发Events、Timers、Orm、RabbitMq等等内容已经无法满足我的探索欲望了，于是乎，就想起之前我一直白嫖的都是七牛云的免费的图床，现在就想自己来开发一个，说干就干！

结果，我发现，这玩意没有想象中那么的好实现，因为我想实现一个类似于MacOs系统上的那种分栏显示的文件可视化的效果，还希望完成上传文件时的一些骚操作，所以最终花费了15天才完全算是开发完成了。

当然这里面有一个内容把我坑的太惨了，因为不想再写新的组件了，所以选择直接使用ElementPlus中CascaderPanel来实现文件分栏(因为实在是太符合我想要实现的最终效果了)，结果却在被刷新分栏数据的时候卡了2-3天，大大拖慢了开发效率(当然除了这个问题之外，其中还有自己摸了2天🐟的原因，不然大概10天就可以写完的)。

这一篇文章，是这个模块开发归纳的第一个模块，主要的作用是用来梳理我再开发过程中用到的知识内容以及相关的注意事项，从Part2开始，就是具体代码实现啦！

当然这里说是一个图床模块，其实已经可以算是一个文件系统可视化模块了，不单单是简单的图床了

1. 文件上传

乍一看这个模块其实没什么意思，就是很普通的文件上传，前端给一个input，设置一下file，就完事了。

当然这么想也没有问题，但是，如果仅仅是这样岂不是很无聊了，而且还会出现很多问题，下面列举一下:

0. 如果是已存在的文件内容，那么还需要重复上传吗？
1. 如果这个图片或者是文件内容过大，那么可能在上传的过程中，遇到断网的情况，导致重传，这就需要重头开始，这样是不是过于浪费资源了？
2. 如何去确定一个文件是否已经上传过了，我们需要对文件做什么处理呢？
3. 假设我们对文件进行了分片处理，然后一个个分片进行上传，完成了断点续传，那该如何保证最后的分片按照顺序组合呢？

带着上面的这几个问题，我们就可以一个一个针对性的去解决，以及处理。

1.1 文件分片

对于断点续传的问题，网上有非常成熟的解决方案，就是对文件进行分片上传，我们都知道文件最终上传到服务器上的时候是一个二进制流，所以我们就需要使用两个对象，分别是Blob与File,我们可以通过这两个对象来对二进制数据进行分片，然后再把一个个分片上传到服务器中去。

当然，为了解决分片数据的最终能够按序组合在一起，我们还需要对数据分片进行编号，避免最终的Merge的时候是无序的，也就还原不出最终的文件了。

而且除了完成数据分片之后，我们还可以将每一个分片数据作为抽样hash的贡献，来计算文件的md5编码，这样就可以来区分是否是上传过的文件。

这里不展开说更多的内容，在后面的Part中在一个个展开，现在可以先去掌握一下Blob与File的使用。

1.2 抽样hash

我想大家一定学习过散列表的相关内容吧，在散列表中，如果我们存放的数据都在一个位置时，就会产生冲突，那么我们就需要对数据解决冲突，比如经常使用的开放地址法和线性探测法。

在找到文件是否存在的时候，我们也可以用散列表处理冲突的方法，来对文件进行处理，产生一个唯一的标识符，来确保文件的唯一性。

那么如何理解抽样hash呢，其实就是基于文件分片的基础上，将每一个分片的部分内容，作为随机贡献，来生成最终的唯一标识符，这样就可以大大的提高文件唯一性的问题，降低错误命中的概率。

其实这里就和布隆过滤器的实现是差不多的，关于布隆过滤器可以看这个: www.bilibili.com/video/BV1zK…

当然这里也不说的太详细，因为后面还会具体展开说的。

2. 文件管理

关于文件管理的内容，主要就是Node中的path模块、fs模块、glob模块的使用了，这三个模块就是核心组成了。

当然除了这三个模块之外，还需要去了解文件系统在操作系统的相关设定，比如权限、软链接、硬链接、文件信息等内容了，只有了解了之后，才能更好的来开发这一块的内容。

关于fs模块的内容，我已经写了一篇文章了，大家可以去看一下：fs模块的使用说明

这里主要再说一些的就是关于一些我在项目中，对整个模块的设计了。

2.1 软链接的使用

为什么要使用软链接呢，我是有以下几点考虑在里面的：

0. 软链接消耗的系统存储空间很小
1. 如果频繁的移动文件的位置的话，需要耗费很多资源，那如果只是简单的移动软链接文件位置，而源文件位置不动，是否可以节约相关资源
2. 因为软链接可以直接获取到原文件的位置的，我们只需要把所有源文件放在同一个位置，这样方便我们去进行相关文件是否存在的查找，不需要在后端代码里面去做很多无意义的文件递归，节省了大量的时间。
3. 软链接的删除不会影响到源文件内容的改变。

除了上面提到这几点之外，还有一些其他的考虑，这里就不再一一列举了，当然，不同的人可能会有不同的想法，我这里觉得软链接好用并不是绝对的，只是为大家提供一个思路。

2.2 为什么使用Mysql来保存数据

用Mysql来存储目录数据与文件数据的好处是显而易见的

0. 可以节约大量的时间，来减少文件或者目录的位置定位，直接在数据库中存储不同目录的位置
1. 为最终的数据可视化呈现提供了便利
2. 可以将每一个文件的外链地址链接进行存储，不需要每一次都在计算生成
3. 等等....

那么这就对我们设计数据表时，有一定的要求，我们需要把我们需要用的所有字段与数据都存储在表中，方便我们的使用。

3. 数据呈现

说到数据呈现这块的内容的时候，我的眼里常含泪水，我真应该自己去写一个简单CascaderPanel而不是使用ElementPlus提供的，我真的花了太多时间在上面了，实在是有点难受，后面去看了源码，才知道怎么去更新指定分栏里面的数据，这里就不做说明了，在后面的单元里面会详细去说我和这一块内容的爱恨情仇了。

当然，除了上面的呈现，我们还需要将数据进行处理，直接从后端拿回的数据一定是不符合我们要求的，所以我们还需要对数据加工一下，把他变成最终我们想要的数据，同时需要去判断这个数据是文件还是目录，因为两者之间存在很大的区别，目录可以展开下一级，而文件不可以。

同时除了呈现之外，我们还需要做一些功能上的完善，比如动态创建文件目录，删除文件/目录，修改文件/目录名称，查看文件/目录详情等相关内容。这些小功能也是算在数据呈现中的

总结

这个大功能模块的开发不是太简单，需要考虑的内容其实还是挺多的，上面这三个方面只是最主要的三个方面，其中还涉及到了很多小细节的完善，这将会在后面的单元中一一列举出来。

当然啦，这也只是我自己一个人琢磨出来的，其中还有很多的不足或者没发现的逻辑不合理之处，也希望读者与我多多交流，这样才能进步，加油加油！