我正在使用Amazon Elastic Transcoder与Lambda和Step Functions一起从WAV文件转码mp3。
我需要在我的数据库中存储转码mp3的MD5/S3ETag标头值。
目前，我必须在一个单独的进程中使用这些来获取这些，这非常慢:
s3_cli = boto3.client("s3",aws_access_key_id=ACCESS_KEY,aws_secret_access_key=SECRET_KEY)
s3_resp = s3_cli.head_object(Bucket=bucket, Key=mp3_key)
s3obj_etag = s3_resp['ETag'].replace('"', '')
在此之前，我希望Elastic Transcoder能在作业响应中提供转码文件MD5哈希值，但我在任何地方都看不到。
有没有人对如何更好地处理这个问题有任何提示，或者我在响应/文档中错过了什么?
我希望Elastic Transcoder能在作业响应中提供转码文件ETag
遗憾的是，它没有
在当前的AWS Python Boto3 1.18.60 SDK(或任何其他SDK包括REST API)中，输出对象的实体标签不会在作业响应对象的任何地方返回。
这是最有可能的,因为一个实体标记代表一个特定版本的对象,主要是用于高效的缓存失效。
Elastic Transcoder作业不会产生相同输出的多个版本，因此，为什么它会返回ETag值?如果有人需要ETag，他们可以从S3对象获得。
另一个问题是，如果大输入有多部分输出会发生什么?SDK返回什么?一个列表的ETag头值?你有多个部分，但是你没有多个版本。
这个实现将违背RFC 7232规范的ETag头:
实体标签是一个不透明的验证器为区分相同的多个表示资源，不管那些多重表示是否存在由于资源状态随时间变化，内容协商导致多个表示同时有效，或者两者兼有。
在这种情况下，您的实际问题是您希望文件的MD5哈希值，即使它们是多部分的。
现在您的代码将为单个文件获取MD5哈希值，但如果它们是多部分的，它们不会像您期望的那样对多部分上传进行哈希。Amazon没有计算整个文件的哈希值，而是计算每个部分的哈希值，然后将其组合成一个单独的哈希集作为ETag头。
这很有意义:它们在接收到每个部分时计算哈希值。在所有部分都被传输后，它们合并哈希值，而不是试图通过读取可能达到AWS对象大小限制的文件来计算最终的MD5哈希值-5tb。当你达到亚马逊的规模时，试着为每个人的文件生成MD5哈希值。你会发现他们的方法很聪明:)
这可能就是为什么S3 API参考中这么说的原因:
ETag可能或可能不是MD5摘要
由创建的对象Multipart Upload或部分复制操作有非MD5摘要的ETags，无论加密方式如何
它是一个MD5哈希值，但是当它是一个多部分上传时，它不是，所以以上在技术上是正确的。
要正确计算多部分上传的MD5哈希值，请尝试查看以下问题的答案:为大于5GB的文件计算Amazon-S3 Etag的算法是什么?
综上所述，不幸的是，您没有从Amazon Elastic Transcoder返回的响应中对象的MD5摘要哈希-您必须自己完成这项繁重的工作&如果你的文件很大，可能会花很长时间。
没有变通或更快的解决方案-您有最快的解决方案，因为您已经以最有效的方式从HEAD获得ETag值。
我可能会建议在尝试确定文件的最终MD5摘要之前，尝试并行化HTTP HEAD请求以获取对象的元数据(s3_cli.head_object(...))。
如果你有500个文件，这肯定会加快速度——不要单独发出API请求。
你绝对可以并行发送它们，所以将你在请求之间花费的时间全部转移到亚马逊的基础设施上。
获取响应&然后处理一起。