关于增加md5戳以后文件越来越多

[leyerzhang]

你好，构建的时候如果一个文件修改重新构建，原来的文件不会被删除，导致文件越来越多，请问该怎么弄？十分感谢！

[fouber]

@leyerzhang

这是什么目录的截图啊，平时开发不用加-m参数，只有上线前才需要。线上是会出现这样的部署的，这是为了性能和安全性考虑。

[leyerzhang]

你好，
1：这个是你们的demo：fis-quickstart-demo；
2：线上部署以后文件越来越多是不是不太好？
3：有一点我不是很了解，增加md5为什么不在文件后面加上查询字符串，就行这样：/modules/collections/todos.js?133d86a；
谢谢！

[fouber]

@leyerzhang

详细的原因可以看一下 这里

这种发布方式叫“非覆盖式发布”，它有很多好处：

1. 部署安全。每次上线，先上线静态资源，它不会覆盖线上文件，然后再上线html页面，就能切换资源了，如果是?xxxx的形式，无论先上线静态资源还是先上线html，都会导致短暂的出错
2. 缓存策略非常简单。基于部署安全，文件都是md5戳做非覆盖式发布的话，可以给静态资源设置10年的强缓存，用户永远不用更新同一个md5戳的文件，性能非常好，缓存策略也非常简单
3. 防止HTTP缓存投毒，具体细节可以看 这里

它只有唯一一个缺点，就是会产生冗余文件。但这完全是值得的。我们计算过，一个中型网站一般需要每3年清理一次md5文件，清理的方式也很简单，一个脚本就搞定了。完全不用在意那些硬盘占用，一个用户上传几张自拍照所占用的空间都够前端开发好几年产生的冗余了。

[leyerzhang]

恩恩，明白了，谢谢

[leyerzhang]

你好，我看了关于“非覆盖式发布”的一些优势，在部署安全方面的确蛮好的，但产生冗余文件过多导致服务端文件越来越多，客户端的缓存文件也会越来越多，客户端是没啥问题，但服务端会不会导致检索文件耗费大量时间使得性能降低？

[fouber]

@leyerzhang

这个可以放心，你也可以先查一下文件检索的相关原理，它和目录下的文件数量没有正比关系。服务器响应请求时查找文件并不是遍历目录，而是定位一个文件，它几乎不受文件数量的影响。

另外，部署后的文件是分目录的，并没有把所有文件发布到同一个目录下，所以，每个文件的md5戳只是在各自的目录下有重复。

而且，文件只有修改了内容才会改变md5戳，同一个工程，实际上文件被修改的数量没有想象中的那么多。你可以回忆一下自己的工程每次迭代，图片icon会有修改么？lib库的js、css会有修改么？其实绝大多数文件没有改变，它们的md5戳还是原来的，没有产生冗余。

md5戳不是随机数，是内容的hash值，与内容唯一对应，这使得每次版本迭代产生的新文件都比较少。加上部署分目录，每个目录下的冗余几年下来修改最频繁的业务代码文件其冗余也不过一两百，完全影响不到检索速度。

md5不是随机数，它与内容唯一对应，只有内容修改了才会产生冗余，很多工程文件其实不会修改。

btw，开发阶段不用给fis release加-m参数，只有上线才需要md5化，也就是说，一般产品一天上线10次算是比较高频率的了，但这10次上线真正产生的新文件有多少呢？其实真没多少。

[leyerzhang]

十分感谢，我主要是不太了解后台，所以问题比较多。。。

[leyerzhang]

你好，又来请教了，我觉得清理文件的脚本也可以作为你们fis项目的一部分，这个应该也可以用node写的吧？

[fouber]

@leyerzhang

在线上环境产出文件通常是由运维完成的，一般都是写脚本删除，这个非常容易，不用fis去做一个这样的功能

[hefangshi]

补充说明一下

实际上要先全量上静态文件的原因归根结底的原因是集群部署的原因而不是时间间隔的原因，如果你是单机的话，即使使用CDN也不要紧。

如果我们同时在集群环境部署模板与静态资源的话，用户访问的新的页面时，如果CDN没有这个文件的缓存，就会向后端请求新的文件内容，而如果我们不先把静态资源在所有集群全部上线，CDN请求的时候就可能落到未上线的机器上，这时就会发生请求失败，而非覆盖式的发布模式就可以先让所有机器的静态资源新老共存，这样发布模板或者html以后，CDN就能正确的获取到最新的静态资源。

[dcy]

平时开发不加-m参数，是开着chrome的dev tool然后禁止缓存这样开发吗

[oxUnd]

平时开发又不开启强缓存，嗯，至少我们提供的服务没有开启。所以，有更新了自然就会请求新的。