fix: Solve the problem of distribute request forwarding failure

[bao11seven]

No description provided.

[qinguoyi]

感谢 @bao11seven 的修复，这是一个非常致命的问题。

/approve
/lgtm

[bao11seven]

感谢 @bao11seven 的修复，这是一个非常致命的问题。

/approve /lgtm

#感谢您的项目，从项目中我收获了很多。在学习的过程中，我发现多分片上传可能仍有需要优化的地方，虽然分片合并文件只会上传一次，但分片文件似乎会上传多次到云存储。通过查询part_info可以解决当前请求重复上传分片，这应该是为了实现断点续传。但对于多次相同切片文件的不同请求，似乎会多次上传到云存储，感觉在分片上传云存储前 需要根据part_info查询md5与分片状态，判断是否需要上传当前分片。 如果是首次则上传，否则就不上传。不上传则将storagename写入part_info，但如果根据这样判断是否上传云存储分片。 如果是首次上传的切片文件，那么根据当前当前删除任务handler应该是适用的，但如果非首次上传，而当前上传合并请求又失败了，删除任务似乎会误删其它请求已上传的切片文件。是否应该在删除云存储的时候查询具有相同storagename并且statu为一的partinfo数目条数，如果等于一，则删除并更新statu，大于一则不删除。而这又涉及是否建立db索引，不知这样的方案是否哪里还有问题🤨

[qinguoyi]

感谢 @bao11seven ，这是一个非常好的问题和想法。

你的疑问，大概是分片数据和合并后的数据都上传到s3中，合并数据做了秒传，但分片数据未做。同时你给出了对应的方案，也看到了方案的问题。

让我们从问题的源头看下，是否需要对分片数据做秒传，如果不需要做秒传，后面的问题也就不存在。

先来看下，大文件分片上传到下载的完整流程：

1. 客户端将文件分片，请求服务端
2. 服务端将分片文件存储在本地，同时将分片文件上传到s3
3. 分片文件上传完，此时触发一个合并异步任务，此时文件的分片flag为true
4. 异步任务将本地的分片文件合并，通过秒传逻辑，上传到s3，同时清理本地文件，将文件的分片flag置为false
5. 下载时，如果文件的flag为true，则会走分片下载，否则走整体文件下载

我们可以看到，问题的本质是，合并文件上传到s3后，本地分片数据会被清理，但s3中的分片数据没有手动清理，这样可能会存在重复数据。于是，也就有了是否做后续分片秒传的疑问。

实际上，在分片数据合并完成后，除了清理本地分片数据，同时也需要清理s3中的分片数据，当分片flag置为false后，分片数据将不再使用，会对存储造成浪费。

这里有两个方案，手动清理和自动清理。

1. 手动清理时，不能合并完成后立即清理，因为不能确定目前是否存在用户正在访问分片数据。你可以设置一个24小时后的定时任务，手动清理s3的分片数据
2. 所谓的自动清理，是指不同厂商的s3都会对分片有清理策略，有定时清理，过期清理，长时间未访问的清理等等。

这个项目写的时候，考虑到分片数据是临时的，用户可以对s3做策略配置，就没有写手动清理的任务逻辑，对你造成了误区，非常抱歉。

[bao11seven]

感谢您的解答，这样也确实避免了逻辑的复杂性，再次思考我的方案，不仅引入了逻辑的的复杂，而且若在面对高并发场景下也引入了并发安全性问题，感谢您优质的项目。