c# - 如何在非常大的输入上没有中间文件的情况下使用 GZipStream 进行多线程压缩/解压缩

Question

• 我想编写一个使用 NET 3.5 和 GZipStream 库执行多线程压缩/解压缩的程序。

• 输入文件非常大(假设有数百 GB)

• 我想在没有任何中间文件的情况下实现这一点。这是我最初的方法，但要求发生了变化。

我正在考虑以下方法，并想验证这在纸面上看起来是否不错:

1. 从源文件中读取并将其拆分为内存中大小不变的 block 。

2. 由于内存有限，请跟踪线程数。

3. 每个 block 都由单独的线程在内存中压缩。

4. 这些压缩 block 以正确的顺序被插入队列。

5. 有一个线程从队列中读取并将其连接到输出文件中。

6. 还将一些有关压缩 block 的元数据存储在某个地方，这些元数据稍后将放入 header 中。我想用它来解压。

完成上述操作后，我对多线程解压的想法将是:

1. 读取有关串联 block 的元数据文件。

2. 以元数据定义的 block 的形式从压缩文件中读取数据。

3. 每个 block 都由内存中的单独线程解压缩。

4. 这些解压后的 block 按正确的顺序添加到队列中。

5. 有一个线程将解压缩的 block 连接成一个统一的输出文件。

上述说法是否合理？

Answer 1

当然，那会很好用。碰巧的是，有效 gzip 文件的串联也是一个有效的 gzip 文件。每个不同的可解压缩流称为 gzip 成员。您的元数据只需要文件中每个流开始的偏移量。

gzip header 的额外 block 限制为 64K 字节，因此这可能会限制 block 的大小，例如大约几十到一百兆字节。出于另一个原因，我建议您要压缩的数据 block 每个至少要有几兆字节——以避免压缩效率降低。

串联的一个缺点是您无法全面检查输入的完整性。例如，如果您以某种方式弄乱了成员的顺序，那么在解压时将不会检测到这一点，因为无论顺序如何，每个成员的完整性检查都会通过。因此，您可能希望包括对未压缩数据的全面检查。一个例子是整个未压缩数据的 CRC，它可以使用 zlib 的 crc32_combine() 从成员的 CRC 中计算出来。

我很想知道在您的情况下，您是否从并行解压缩中获得了显着的加速。解压缩通常足够快，以至于它在正在读取的大容量存储设备上受到 I/O 限制。