我正在使用 Amazon SES 发送电子邮件，并且想知道如何在失败的情况下正确处理重试。
假设我向操作发出POST请求SendEmail，但收到超时。无法知道消息是否已发送。
是否可以为每封电子邮件发送一个唯一标识符，以便我可以安全地重试发送这封电子邮件，让 SES 发送邮件，或者告诉我它已经发送？
否则，在网络错误的情况下，我必须在冒两次发送电子邮件的风险和根本不发送电子邮件之间做出选择。
问问题
1751 次
1 回答
7
根据 SendRawEmail 的SES API 参考，您在请求中提供的唯一参数是收件人列表、电子邮件正文和您的源地址。不幸的是，很明显，如果您收到超时而不是 SES 的响应，则无法知道该特定电子邮件是否已发送。我知道这很令人不安。我也讨厌这种情况。
但是，在找出解决这一困境的最实用的解决方案时，您确实有一些选择。您可以一揽子决定永不重试，并假设未发送的消息比重复的消息更好。您也可以一揽子决定重复电子邮件是完全可以接受的。然而，我首选和推荐的方法是学术上不太令人满意但务实的中间立场。让我解释。
当与新服务集成时，您会发现一个您不知道如何处理但您不希望经常发生的边缘情况，最好的办法是收集更多信息并同时手动处理事情。罗马不是一天建成的，您的云服务在您打开它的第一天就无法完美运行。相反，当您遇到超时时，请将其记录下来并保存以后可能需要重新发送该电子邮件的任何内容。
现在，假设您已经完成了编码和集成测试，并且您已经在生产环境中启用了该服务。第一天，您尝试发送 100,000 封电子邮件。如果你得到 1000 次超时，那么就会发生一些非常奇怪的事情，你知道你需要调查你的网络！相反，如果在第一天，您得到 0 次超时，在第二天也是如此，然后在第七天，在一周的 700,000 次尝试中，只有 1 次超时。如果合适，您可以尝试致电该 1 位客户并说“嗨，很抱歉打扰您，但我们确实致力于可靠性，但我们遇到了技术问题。我想确保您收到 [XYZ] 的电子邮件收据。 " 如果他们说不，那么返回并更改代码可能是有意义的，以便在超时时，您只需等待几秒钟后重试，因为您知道它可能会起作用。两者之间的任何事情都有相同的想法。
这里的重点是你将把你的人类智慧应用到这个谜团中。我发现不试图超越未知往往更容易。只要让自己能够处理任何发生的事情，并弄清楚当你知道问题到底是什么样子时，明智的做法是什么。
（您可能会喜欢这篇由其他人撰写的关于“不处理边缘情况”的博文。）
于 2013-07-10T23:15:15.637 回答