大文件上传与存储方案探索
在一个过往的项目中，我面临了一个特别的挑战，那就是如何帮助用户上传大约1.5G的压缩包至后端服务器（OSS）以供其他用户下载。我的任务是寻找并实现一个高效的解决方案。
在这个项目中，我主要的关注点在于以下几点：
- 能够快速、稳定地将大文件上传至服务器并存储，随后供其他设备下载。
- 在网络条件不佳的情况下，能够实现断点续传功能。
- 当不同用户尝试上传同一文件包时，能够实现秒传。
为了达成这些目标，我进行了如下的技术实践和方案制定：
我们采用了spark-md5来计算文件内容的hash值，以确定文件的唯一性。通过这个值，我们可以对文件进行初步的校验和筛选。
流程为先计算文件的hash，接着发送到后端进行状态查询。我们预期的文件在服务器的存储情况有三类：未上传、已上传、上传部分。这个步骤中，我们设定了固定的分块大小来简化处理。
根据后端返回的状态，我们执行不同的上传策略。如：
- 对于已上传的文件，直接进行秒传操作。
- 对于未上传或只上传了部分的文件分块，我们进行计算并执行相应的上传策略。
- 同时使用多个HTTP请求进行并发上传，确保最多有5个请求同时进行（根据浏览器并发限制）。
- 当所有分块都上传完毕后，向服务器发送合并指令，实现服务端存储。
这里重点介绍我们的关键技术和实施策略：
- 分块处理与并发上传：通过将大文件切割成多个小文件块，通过并发多HTTP请求进行快速上传。
- 文件状态预查询：通过文件hash查询后端存储状态，通过状态决定需要上传的分块。
- 断点续传与秒传：利用分块信息与后端交互，实现断点续传与秒传功能。
- 利用web worker进行hash计算，提高计算效率。
在此方案中，我们选用的环境条件是每个文件分块5M。而在实际的网络环境（10M/s的带宽）与服务器配置（2台4核32G服务器）下进行了测试。
欢迎各位同仁交流学习、优化方案，共同成长。
请注意：我们坚信每次的合作与交流都能让我们的技术得到成长和进步。
[参考资料] 无需具体展示，但感谢大家的技术交流与支持]