如何避免向Amazon SES提交双重提交？

Question

我正在发送有关Amazon SES的电子邮件,我想知道如何在发生故障时正确处理重试.

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

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

否则,我必须选择,在网络错误的情况下,冒险发送电子邮件两次,而不是发送电子邮件.

Answer 1

根据SendSawEmail 的SES API参考,您作为请求的一部分提供的唯一参数是收件人列表,电子邮件正文和源地址.不幸的是,似乎很清楚,如果你得到超时而不是来自SES的回复,则无法知道是否发送了该特定电子邮件.我知道这很令人沮丧.当我处于那种情况时,我讨厌它.

但是,在确定解决这一两难问题的最实际解决方案时,您确实有一些选择.您可以做出永久性重试的一揽子决定,并假设未发送的消息优于重复消息.您还可以做出一揽子决定,即重复的电子邮件是完全可以接受的.然而,我的首选和推荐的方法是在学术上不那么令人满意,但务实的中间立场.让我解释.

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

现在,假设您已完成编码并进行集成测试,并且您已在生产中启用了该服务.第一天,您尝试发送100,000封电子邮件.如果你得到1000次超时,真的很奇怪,你知道你需要调查你的网络!相反,如果在第一天,你获得0次超时,第二天相同,然后在第七天,在本周的700,000次尝试中,只有1次超时.如果合适的话,你可以尝试给那个客户打电话并说"嗨,很抱歉打扰你,但我们真的致力于可靠性,我们遇到了技术问题.我想确保你收到[XYZ]的电子邮件收据. " 如果他们拒绝,那么,返回并更改代码可能是有意义的,以便在超时时,您只需等待几秒钟后重试,因为您知道它可能会起作用.任何介于两者之间的相同想法.

这里的要点是,你将把你的人类智慧运用到神秘之中.我发现通常更容易尝试超越未知.只是让自己能够处理发生的事情,并找出聪明的事情,当你知道问题的真实情况时.

(您可能会喜欢这篇由其他人撰写的博文 - 关于"不处理边缘案例".)