我们刚刚在软件中添加了一个自动更新器，并得到了一些错误报告，
自动更新无法正确完成，因为下载的文件的sha1校验和不匹配。我们托管在Amazon S3上...

这可能是我的代码有问题，或者是S3有问题。

我重新阅读了可疑内容的代码，并编写了一个简单的脚本来下载并检查下载文件的校验和，确实确实偶尔出现了一些错误(昨天有40个错误中的1个)。今天看来还可以。

你有遇到那种问题吗？有某种解决方法吗？

额外信息：测试在日本进行。

解决方案

回答

除了几周前的停机时间。我没有听说过。
考虑到一次宕机是由于在云中级联的模糊服务器错误，他们做得很好。他们对此很开放，并一发现就解决了。(这发生在一个周末，iirc)

因此它们非常可靠。我的建议是仔细检查代码。如果仍然有问题，请将其提供给Amazon支持。

回答

我同意，对代码进行四遍检查将是一个好主意。我并不是说这不可能发生，但是我不相信我曾经见过，而且我现在已经相当好地使用过S3. 但是，我管理不当的异常/连接中断了几次，最终出现了与我期望的不符的片段。

如果他们确实发送了错误的数据，我会感到非常惊讶，但是像往常一样，一切皆有可能。

回答

我认为我收到了一个错误403，而不是发送错误的数据。如果我再试一次，通常没问题。

我同意：我看到许多关于人们谈论亚马逊完全瘫痪的报告，但是没有人谈论"有时我的访问被拒绝"错误，所以我想这可能是我的错误。我只是在亚马逊上设置了日志。

反正谢谢你！我会按照建议，不要再责怪"另一个人"。

回答

我偶尔会遇到GETs对象意外的404错误，该对象是前面的LIST的一部分，但对于存储桶来说是新的，还有其他杂项。错误(例如：我的访问ID和密钥上的403)，但没有造成灾难性的后果。

我的代码运行服务器端，所以我把一些可靠的错误处理和日志记录。我认为，只要网络上有一台服务器与另一台服务器通信，这是明智的选择。 ：P

回答

亚马逊的S3偶尔会因上传或者下载过程中的错误而失败-通常为" 500：内部服务器"错误。错误率通常很低，但是如果服务负载很大，则错误率可能会上升。错误率永远不会为0％，因此即使在最佳情况下，偶尔的请求也会失败。

我们是否正在检查自动更新程序中的HTTP响应代码？如果不是，则应在执行校验和之前检查下载是否成功(HTTP 200)。理想情况下，应用应重试失败的下载，因为瞬时错误是客户端需要处理的S3不可避免的"功能"。

值得注意的是，如果客户遇到500个错误，则我们可能不会在S3服务器日志中看到任何有关这些错误的证据。这些错误似乎在请求到达服务的日志记录组件之前发生。

回答

在下载过程中从未听说过问题。那真是怪了。上传时，我收到500吨内部服务器错误消息。这就是为什么我有一个守护程序在用户执行其他操作时上载。

代码中似乎没有什么问题，也许S3(或者S3-> Japan)确实有问题。

我们可以尝试启动EC2服务器，然后从那里运行测试(流量不会花费任何金钱，因此我们可以随意使用它！)，看看是否出错。如果这样做，那么我们就不走运了，S3不适合我们:)

祝你好运！

回答

好的，这现在有点旧了，但仅供参考。我一直在运行将数个千兆数据的数据从EC2服务器直接迁移到s3的数据。我大约每10分钟就会收到500个错误，代表大约1％的PUT错误率。因此，是的，S3确实存在500个错误的问题。

尽管在GET方面做得还不够，所以无法发表评论