覆盖式发布与非覆盖式发布

 

最早在Q群出现一个这样的问题：  缓存更新问题，第一个文件名更换 与第二个文件query更换 哪个更好？

 

经过FIS(fis.baidu.com)Q群的漂流瓶前辈的解答下有了比较详细的认知。

 

上图中的第一个 属于  非覆盖式发布    （修改了文件名，这个叫非覆盖式发布，它不会覆盖线上的文件）

　　　　第二个 属于  覆盖式发布 （ 同样的文件名，这个叫覆盖式发布，它会覆盖线上的文件）   

 

通过一个举例来证明下那个方式更合适吧：

 

 

假设，标红的index.html和a.js是这次修改了的文件，待上线，即将覆盖线上的同名文件对吧

 

好了，请思考：

对于一个有着1000w日pv的网站，如果要这样上线，是先覆盖a.js呢，还是先覆盖index.html呢

 

这个时候 问题就变得不好回答了

尤其是当大型网站的静态资源是部署到CDN上的时候，a.js的部署时间，和模板的部署时间间隔非常大

这个期间有很多用户会访问页面，他们最终会得到一个不匹配的页面和静态资源 

老页面 + 新js 或者 新页面 + 老js 

 

 这种“细微”的差别，在稍大一些的互联网产品上会被放大，影响深远 

　

这就是 覆盖式带来的问题。

 

那么现在的答案是 选择 非覆盖式发布

 

 

问题又来了：  增量发布，多久清一次文件 （因为md5戳带来的文件名差异 之前的版本还存在于服务器磁盘中）

 

一个中型产品线，大概每3年会累积200多m的冗余文件，可以考虑清楚一下（ 这个前提是基于md5戳的情况）如果是基于构建版本的，要高很多

1. 文件定位和文件数量没关系，所以文件多了其实也没有什么实质影响
2. 磁盘空间真的很多啊，这个更不用担心了。网站的某个用户，出去玩一次自拍的照片都上传了，所占用的公司服务器磁盘空间应该够产品研发好几年的占用了
3. 打不了写个脚本清理一下，或者用别的什么方式保证一下，总之，非覆盖式发布是目前解决缓存、部署安全等问题的最好方案了，其中以md5戳最优

 清除旧文件

你可以保留fis的map.json，然后照着这个清
你也可以写个脚本，按照最后访问时间清