我正在使用 DotNetZip 库将数据流压缩到 Zip 文件中以便存储。 DotNetZip 能够进行多线程压缩，而且速度快。
我发现的所有库都是单线程解压的。
这是一般 ZIP 格式的缺点吗？ .Net世界有没有多线程的Unzip功能？ (有 Stream 接口(interface)？)
如果不是.. 是否有技术原因导致无法实现？
附加信息: 被压缩的数据是 SQL Server 数据库备份，大小约为 30 Gb，从 SQL Server 备份命令 (VDI) 通过 ZipOutputStream 流式传输到 FileStream。
最佳答案
这在技术上并非不可能。
DotNetZip 不做多线程解压，因为我从来没有实现过它。 MT压缩优先；我做到了。我只是懒得做 MT 减压。与解压相比，压缩通常是一个更耗费 CPU 资源且成本更高的操作；由于搜索要求，对于 DEFLATE(ZIP 存档中使用的典型压缩算法)尤其如此。虽然我不是压缩算法专家，但我猜类似的特性也适用于其他压缩算法。解压时不需要查找，所以解压速度一般都比较快。出于这个原因，优化 DotNetZip 中的解压缩不是一个优先事项。
旁注:DotNetZIp 中的并行压缩是在单个文件上完成的:假设您有一个包含 1000 个 block 的文件(对于任意 block 长度)。 DotNetZip 将征用多个线程进行压缩，每个线程压缩一个 block 。因为压缩器线程独立运行，例如， block 6 的压缩可能会在 block 4 的压缩之前完成。因此，主线程负责将压缩 block 重新组合成正确的顺序，然后将它们写入输出流。
这样，在库开始压缩下一个条目之前，zip 存档中的每个条目(文件)都被完全压缩。显然有机会在压缩期间应用额外级别的并行性:并行压缩多个条目。 DotNetZip 现在不这样做。当正在创建的 zip 文件由大量较小的文件组成时，这种并行方法是有意义的，而 DotNetZip 今天所做的并行压缩在 zip 存档包含任意数量的较大文件(大于 512k 左右)时才有意义。
今天使用 DotNetZip，在典型的现代笔记本电脑上，CPU 在压缩大文件时会饱和，这些文件有超过 10 个左右的 block ，典型的 block 大小为 512k。因此，添加新级别的并行性根本不会加速该场景。但这将有助于将 70,000 个小文件压缩到一个存档中。
关于.Net多线程解压，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7099506/