从nas硬盘大量解压缩zip文件的性能问题

“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决.”

一个名人说的，也是我们解决问题主要的一种方式。我们总是想设计做到“透明”。提供很高的服务给下一层服务，你不需要管中间的细节，你调用就好了。

不会存在只有一面的硬币。记得读书的时候，计算机历史中就有人想把API调用都设计成一样的，本地调用和网络调用看起来是一样的，但是这期间的时间差，如果不仔细考虑，那么上层的代码就无法使用。（如果是网络调用，你需要读取很大的内容来反复处理，如果是从内存读取内容，就可以把代码写的更好读，一次一次遍历。）

这次的任务是在Linux服务器上，有很多zip文件需要进行解压缩任务，然后再copy到另一台nas机器上。文件一共是几百万左右，最开始就没什么都没想，只把工程完成就好了。然后就交给机器去跑。

但是第二天发现，工作的很慢，然后没想太多，想提供多线程去优化。反正就是改写到10个线程同时处理。然后发现还是没有想象的快。一直认为是apache zip是不是有什么性能问题。不理解为什么他们这么菜。哈哈

其实这里面还是涉及到太多的底层，有自己无法理解的地方。问了一下人工智能。它给出的方案是先copy到本地，然后再加压缩到目标nas。

我还是理解不了上诉方案，因为copy到本地在解压缩，就相当于。Nas硬盘->内存->网络->本机内存->本地硬盘。 然后再解压缩。

如果直接取数据不是相当于Nas硬盘->内存->网络->本机内存-> 然后直接处理了。减少了本机写硬盘的时间。（这个问题之前遇到过，也没想通。）

后来想看看nas的底层原理，使用mount看了一下是使用的什么协议。

xx.xxx.xxx.xxx:/ /SFTP on /xxxx type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.67.38.149,local_lock=none,addr=xx.xxx.xxx.xxx)

这是NFS协议的具体细节：

• 协议版本: NFS v4.1（通过 vers=4.1 指定）。
• 传输协议: 使用 TCP（通过 proto=tcp 指定）。
• 其他选项:
  • 读/写大小: rsize=1048576, wsize=1048576（每次读写数据块大小为1MB）。
  • 超时和重传: timeo=600, retrans=2（传输超时时间和重传次数）。
  • 安全: sec=sys（表示基于系统的安全方式）。

总之，所有的挂载路径都使用了NFS v4.1协议来进行网络存储访问。

看了以后发现自己的代码

byte[] buffer = new byte[1024];
try (ZipFile zipFile = new ZipFile(file)) {

使用的是1k的缓冲，但是nas使用的是1M的缓冲，那么用脑子想想（还没有进行验证）应该是造成了nas缓冲的大量浪费。如果把代码里面的缓冲设置成大于或者等于nas的缓冲就大可以大幅度提高效率。回来有机会可以试一下这次猜想。

还有就是任何一层都无法做到完全透明，如果你想做好，那么你就需要了解底层原理。但是还是会减少了大量的编码成本。而且在不在意效率的情况下，普遍还是工作很好的。