大文件分片、秒传、断点续传
大文件分片、秒传、断点续传
小奥大文件分片、秒传、断点续传
对于文件上传来说，如果是一个小文件，那么可以直接把文件转化为字节流上传到服务器，但是在文件比较大的情况下，用普通的方式进行上传、下载，都是不可取的，很容易导致内存问题。所以对于大文件来说，采用分片上传，利用多线程并发上传能够达到最大的效率。
具体实现这里不再介绍，有很多优秀的文章可以参考，如下：
下面我们简要介绍实现功能的逻辑以及存在的问题如何解决。
分片上传
将大文件切分为多个小的数据块（通常大小为1MB~10MB），然后将这些小数据块分别上传至服务器，最后由服务器将这些小块组合成完整的文件。这种方式可以避免由于网络中断或超时而导致上传失败，并且能够更好地控制上传进度。
分片上传逻辑
- 客户端将文件切成固定大小的块（例如每个块的大小为1MB），并为每个块生成唯一的标识符。
- 客户端逐个上传每个块到服务器。上传时，客户端将块的标识符和块数据一起发送给服务器。
- 服务器接收到每个块后，会将块数据存储到临时文件中，并在服务器端记录每个块的标识符和位置。
- 当所有块都上传完成后，客户端向服务器发送一个“合并请求”，请求服务器将所有块合并成一个完整的文件。
- 服务器接收到“合并请求”后，根据之前记录的块标识符和位置信息，将所有块合并成一个完整的文件。
- 服务器将合并后的文件存储到指定的位置，并返回上传成功的响应给客户端。
- 客户端收到上传成功的响应后，通知用户上传已完成。
秒传
用户上传一个已存在于服务器上的文件时，可以通过秒传技术来快速完成上传过程。具体实现方式是，客户端计算文件的哈希值（如MD5），然后向服务器发送这个哈希值。如果服务器已经存在这个哈希值对应的文件，那么服务器会直接返回已存在的文件，从而实现秒传。这种方式可以节省上传时间，并且减少网络带宽的使用。
核心逻辑：
- 利用redis将文件分片的信息存储到hash中
- 首先检查文件是否已经被上传过 （key为md5，value为文件名、大小、文件地址等）
- （1）检查在磁盘中是否存在 –> 通过指定的名称格式查询文件路径
- （2）检查在Redis中是否存在，并且所有分片都已经上传完成
- 如果文件存在，则直接返回true，上传成功
- 如果文件不存在，则进行断点续传逻辑，返回已经上传的分片
断点续传
当上传过程中网络中断或上传过程被用户取消时，可以通过断点续传技术来恢复上传过程。具体实现方式是记录已上传的文件块和上传进度，当用户重新上传时，从上次中断的地方继续上传。这种方式能够提高上传的效率，并且避免重复上传已上传的文件块。
逻辑
客户端与服务端重新建立连接之后，客户端发送请求文件信息，如果存在未上传完成的分片信息，会向服务端发送上次传输的字节数和文件位置信息，服务端根据该信息返回当前传输的位置，客户端会从当前位置继续上传文件。
使用Redis可以将已上传的数据块存储在一个Redis的有序集合数据结构中，其中每个数据块的键值为一个特定的前缀加上一个唯一的ID，有序集合的分值为数据块的序号。上传文件时，每上传一个数据块就将它添加到有序集合中。如果上传中断，可以查询有序集合中已上传的数据块，然后从最后一个已上传的数据块处继续上传即可。
存在的问题
如何设置文件分片的唯一标识
每个数据块的唯一标识通常是一个随机生成的字符串或数字，用于在客户端和服务器之间唯一标识每个数据块。这个唯一标识可以是文件名、文件大小、块序号、当前时间等信息的组合生成的哈希值，也可以是使用UUID等算法生成的唯一标识符。在上传过程中，客户端需要将每个数据块的唯一标识和数据内容一同上传到服务器，以便服务器能够将每个数据块存储到正确的位置。服务器会将每个数据块的唯一标识和对应位置信息记录下来，以便在最后将所有数据块合并成完整的文件时，能够找到每个数据块的正确位置。
文件上传耗费资源在哪里
（1）网络带宽消耗： 大文件上传会占用服务器与客户端之间的网络带宽。如果多个用户同时上传大文件，服务器的总带宽使用量可能会增加，导致慢速的响应或其他用户体验问题。
（2）存储消耗： 大文件需要占用服务器的存储空间。如果服务器的存储容量不足，或者存储速度较慢，可能会影响其他服务器功能和性能。
（3）CPU 使用率： 服务器需要对上传的文件进行处理，例如验证、解析或存储。大文件可能需要更多的CPU资源来处理，特别是在进行一些复杂的操作时。
（4）内存消耗： 在文件上传的过程中，服务器可能需要将文件的部分或整个内容加载到内存中进行处理。大文件可能需要更多的内存，如果服务器的内存资源有限，可能导致性能下降。
（5）文件IO操作： 将大文件写入磁盘或从磁盘读取文件都涉及到IO操作。如果服务器的磁盘速度较慢或者磁盘负载较高，可能会成为性能瓶颈。
如何评估分片上传时间
（1）分片生成时间。通过对每个分片生成所花费的时间进行评估。包括文件读取、分片切割（和压缩，如果存在）的过程。可以简单使用时间戳的方式来计算时间。
（2）分片上传时间。如果分片上传到服务器，那么就评估每个分片上传到服务器的时间。这会涉及到网络传输时间。
（3）整体上传时间。考虑整个大文件上传的总时间。包括生成分片、上传分片、服务器处理以及合并分片的时间。
（4）并发上传时间。如果支持并发上传多个文件分片，那么可以通过线程池或者并发机制来模拟多个分片同时上传，然后测量整体时间。
（5）网络延迟和带宽。评估网络传输的性能，包括延迟和带宽，这可以通过测量文件分片的传输速度和服务器响应时间来实现。
（6）监控和日志。可以在代码中添加适当的监控和日志，记录文件分片生成和上传的关键步骤的时间戳，这样可以方便后续分析日志，排查耗时模块以便进行优化。
在评估时，要考虑网络波动、服务器负载等因素，以更准确地估计实际部署环境下的性能。
如何确定文件分片大小
确定大文件分片大小需要综合考虑多个因素，以确保在上传过程中达到最佳性能。以下是一些影响分片大小选择的关键因素：
（1）网络传输性能。较小的分片可以提高对网络的利用率，尤其是在高延迟或低带宽的网络环境中。然而，如果分片太小，可能会导致上传过程中的开销增加。因此，需要权衡网络传输性能和分片数量。
（2）服务器处理能力。服务器需要处理接收到的分片，较小的分片可能导致服务器面临更多的请求，从而增加服务器负载。在选择分片大小时，要考虑服务器的处理能力，以确保服务器可以有效地处理分片。
（3）客户端资源。较小的分片可能会增加客户端的处理负担，包括文件读取和分片生成的开销。要确保客户端能够有效地生成和上传分片。
（4）文件系统和操作系统的限制。操作系统和文件系统可能对文件大小有限制，因此要确保选择的分片大小在这些限制范围内。
（5）并发上传。如果支持并发上传多个文件，较小的分片可能有助于更好地利用服务器和网络资源，提高并发性能。
（6）重试机制。较大的分片可能导致在传输过程中发生错误时需要重新上传较大的数据块。选择适当的分片大小可以最小化因错误而需要重新上传的数据量。
（7）应用场景和需求。具体应用场景和需求也是影响分片大小的因素。例如，对实时性要求较高的应用可能会选择较小的分片，而对于批量上传的应用，可以选择较大的分片。
（8）安全性。如果安全性是一个重要考虑因素，较小的分片可能更容易管理和控制。此外，可以考虑对分片进行加密以增强安全性。
（9）网络请求成本。每个分片通常都需要一个独立的网络请求。因此，选择适当的分片大小还应该考虑减小网络请求的成本，尽量减少不必要的开销。
在实际应用中，需要进行一些实验和性能测试，通过不断调整分片大小并观察性能表现，找到最佳的分片大小。综合考虑上述因素，根据具体情况选择一个平衡性能、资源利用率和系统复杂性的分片大小。
如果分片过多应该如何处理
当大文件分片上传的过程中分片过多时，可能会引发一些问题，包括网络负载增加、服务器负担过重、上传速度下降等。为了处理这些问题，可以考虑以下策略：
（1）调整分片大小：如果分片过多，可以考虑增加每个分片的大小。较大的分片数量更少，减少了网络请求的次数，从而减轻了服务器的负担。然而，分片大小的选择仍需要平衡上述提到的因素。
（2）限制并发上传数：实施并发上传的限制，限制同时上传的分片数量。这可以通过使用线程池或其他并发机制来实现。限制并发上传可以减缓上传速度，但有助于维持系统的稳定性。
（3）使用流式上传：考虑实施流式上传，即在生成和上传分片的同时，不必等待整个文件的所有分片生成完毕。这样可以减小整体上传时间，同时降低服务器负担。
（4）服务器负载均衡：如果分片上传负载分布不均匀，可以考虑使用负载均衡机制，将上传请求分配到多个服务器上，以提高系统整体的处理能力。
（5）自动调整分片数量：实施自动调整分片数量的策略，根据系统负载动态调整分片大小或数量。这可以通过监控系统性能，自动调整上传参数以适应当前负载情况。
（6）断点续传和重试机制：支持断点续传和重试机制，以防止上传过程中的失败。这样即使有大量分片需要上传，也能够在失败后恢复上传过程，减少数据的重传量。
（7）优化上传算法：使用高效的上传算法和协议，例如HTTP/2或其他支持多路复用的协议，以提高分片上传的效率。
（8）压缩和加密：在分片生成时进行压缩和加密，以减小分片的大小，从而减少上传的数据量。但要注意，压缩和加密也会增加分片生成的计算开销。
综合考虑这些策略，可以根据具体情况采取不同的措施来处理分片过多的问题，以保证大文件分片上传的效率和稳定性。
分片上传一半出现问题如何处理
如果在分片上传的过程中，由于网络的原因导致某个分片只上传了一半，那么该如何处理？
在大文件分片上传的过程中，如果一个分片只上传了一半，通常情况下，上传程序应该能够自动检测到上传失败，并且重新上传该分片。
- 如果程序支持断点续传，则它会尝试恢复上次中断的进度，从上次传输失败的位置继续上传，也就是只会传输剩下部分的数据，而不是整个分片。
- 如果程序不支持断点续传，那么必须重新上传整个整个分片。
分片信息应该如何存储
在大文件分片上传场景中，我们可以使用Redis来存储上传分片的信息，以方便查重和断点续传。
具体来说，我们可以将每个分片的唯一标识作为Redis的key，将分片数据的校验值和其他元数据作为value存储在Redis中。在上传每个分片时，客户端可以通过Redis判断该分片是否已经上传过，并校验分片的完整性；在合并分片时，服务器端可以通过Redis读取每个分片的元数据，并将它们按顺序合并成完整的文件或对象。
