S3上传时报错：Data read has a different length than the expected

报错信息

在将数据上传到 S3 时发现许多错误。

首先,所读数据长度不同于例外的长度:数据Length=15932;例外Length=19241。

当发现文档的实际长度和文档的预期长度在上传后不一致时,就会发生这种错误。

以下是整个错误报告堆栈 :

其次,无法计算用于/tmp/78c20e3adeb12022ade4ceb002c4cf4bd9e的MD5大麻,因为没有这种文件或目录。

此错误显示 s3 在上传文档前先对文档进行 MD5 校验。 所提供的文件在此过程中被发现不存在 。

此堆栈信息较少 :

原因推测

于是推测，第一种问题应该由正在上传的 s3 文档造成。因此,文件已经改变。而且可以看到，所报告的大多数错误都长于数据链的长度。这是否是张贴该信的适当时间?此文件是否被更改或重写?因此,在改写时,文件是不完整的，因此长度不一致。

代码排查

于是我们通过代码挖掘发现 上传算法的这一部分 很可能是相同的:

1. 要构建 md5 值, 请使用时间戳拼写文件名称。 将此视为 s3- key 。
2. 直接返回 md5key 并保存在库中。 我们接下来通过线索库执行上传逻辑 。
   1. 接收附件 URL 并在本地服务器上将文件保存为 md5key.Jpg 。
   2. S3呼叫 然后上传 md5key.Jpg
   3. 删除文件 md5key.Jpg

问题就出现在这里！

1. 三个链接的 md5 key 是否相同? 如果商业方提供几个相同的附加链接( 链接 A、 链接 A、 链接 A ), 并且它们在整个处理过程中在相同毫秒内创建 md5 key?
2. 由于三个文件由线索库处理, 线索 1 将写入文件到 md5key. Jpg 并开始上传。 线索 2 然后开始将文件写入 md5key. jpg 并开始上传。 当第 1 行的上传逻辑显示文档的长度不同时, 上传失败 。
3. 当第二行被输入 md5key 。 这个项目是我们对2011年埃及抗议的特别报道的一部分。线程3也开始写入。当线程3写入完成，准备上传时，这次是通过上传第二线完成的此外,除掉Md5key,这不是一个好主意。因此,Tread 3的文件丢失了。因此,记录了第二个错误。文件不存在。

调查结果经过审查,并被确定为原因,有很多事需要考虑。

结论

1. 读取数据的时间长度与错误的时间长度不同,当文档准备上传时,该错误可能会被另一个写线所覆盖。问题可以沿着该行回答。
2. 如他所说, 找不到这样的文件或错误 。 让我们来调查为什么文件丢失。 检查一下程序是否有逻辑删除它 。