如何避免重复提交到 Amazon SES？答案

【问题标题】：How to avoid double submissions to Amazon SES?如何避免重复提交到 Amazon SES？
【发布时间】：2017-01-03 01:56:52
【问题描述】：

我正在使用 Amazon SES 发送电子邮件，并且想知道如何在失败的情况下正确处理重试。

假设我向SendEmail 操作发出POST 请求，但收到超时。无法知道消息是否已发送。

是否可以为每封电子邮件发送一个唯一标识符，以便我可以安全地重试发送这封电子邮件，让 SES 发送邮件，或者告诉我它已经发送？

否则，在网络错误的情况下，我必须在冒两次发送电子邮件的风险和根本不发送电子邮件之间做出选择。

【问题讨论】：

您目前是否使用 AWS 开发工具包发送电子邮件？我正在使用 PHP SDK，在触发 SendEmail 后，会有一个响应指示是否发送了电子邮件（检查github.com/aws/aws-sdk-php/blob/master/src/Aws/Ses/Resources/…）。然后我可以记录这个结果，接下来的事情就很简单了
@Hieu 是的，我愿意，是的，亚马逊确实返回了发送状态。我的意思是，如果邮件 not 发送是因为 HTTP 请求没有收到响应，或者 PHP 以致命错误退出，或者任何类似的，那么就没有办法知道是否我是否需要再次发送电子邮件。我有一个 cron 批处理待处理的电子邮件，我希望能够询问“ID 为 123 的电子邮件是否已发送？”
嗯，然后在 SDK 中，您可以使用 GetSendStatistics() 方法来获取使用情况统计信息。在此处阅读更多信息：“使用 Amazon SES API 监控您的使用统计信息”docs.aws.amazon.com/ses/latest/DeveloperGuide/…。希望它有所帮助;)
问题是，如果您发送两次或根本不发送，究竟会发生什么以及更可取的情况。实际上电子邮件并不可靠，因此有时消息甚至可以被目标服务器接受，然后由于某种原因被丢弃。您需要更好地描述这些消息的消费者才能正确接收建议。顺便说一句，您可以查看发送消息时返回的错误，以判断您的请求是否可以到达亚马逊。

标签： amazon-web-services amazon-ses

【解决方案1】：

根据 SendRawEmail 的 SES API Reference，您在请求中提供的唯一参数是收件人列表、电子邮件正文和您的源地址。不幸的是，很明显，如果您收到的是超时而不是 SES 的响应，则无法知道该特定电子邮件是否已发送。我知道这很令人不安。我也讨厌这种情况。

但是，您确实可以选择一些最实用的解决方案来解决这个难题。您可以一揽子决定永不重试，并假设未发送的消息比重复的消息更好。您也可以一揽子决定重复电子邮件是完全可以接受的。然而，我首选和推荐的方法是学术上不太令人满意但务实的中间立场。让我解释一下。

与新服务集成时，如果您发现不知道如何处理但您不希望经常发生的边缘情况，最好的办法是收集更多信息并在与此同时。罗马不是一天建成的，您的云服务在您打开它的第一天就无法完美运行。相反，当您遇到超时时，请将其记录下来并保存以后可能需要重新发送该电子邮件的任何内容。

现在，假设您已经完成了编码和集成测试，并且已经在生产环境中启用了该服务。第一天，您尝试发送 100,000 封电子邮件。如果你得到 1000 次超时，那么就会发生一些非常奇怪的事情，你知道你需要调查你的网络！相反，如果在第一天，您得到 0 次超时，在第二天也是如此，然后在第七天，在一周的 700,000 次尝试中，只有 1 次超时。如果合适，您可以尝试致电该 1 位客户并说“嗨，很抱歉打扰您，但我们确实致力于可靠性，但我们遇到了技术问题。我想确保您收到 [XYZ] 的电子邮件收据。 "如果他们说不，那么返回并更改代码可能是有意义的，这样当超时时，您只需等待几秒钟后重试，因为您知道它可能会起作用。两者之间的任何事情都是相同的想法。

这里的重点是你将把你的人类智慧运用到这个谜团中。我发现不试图超越未知往往更容易。只需让自己能够处理所发生的任何事情，并弄清楚当您知道问题的真实情况时该怎么做才是明智之举。

（你可能会喜欢这个blog post——由其他人写的——关于“不处理边缘情况”。）

【讨论】：