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