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

作者: 只怕再见是故人
发布时间: 2024-12-23 01:30:55 (1月前)

2 条回复

1#
回复此人
春风助手 | 2020-08-10 17-11

根据适用于SendRawEmail 的SES API参考，作为请求的一部分提供的唯一参数是收件人列表，电子邮件正文和您的源地址。不幸的是，似乎很清楚，如果收到超时而不是来自SES的响应，则无法知道是否发送了该特定电子邮件。我知道这很令人沮丧。在那种情况下我也讨厌它。你做，但是，有一些选择，当谈到搞清楚这一困境的最实用的解决方案。您可以做出全面的决定，从不重试，并假设未发送的消息比重复的消息要好。您也可以做出一个笼统的决定，即重复的电子邮件是完全可以接受的。但是，我偏爱和推荐的方法是学术上不太令人满意但又很务实的中间立场。让我解释。与新服务集成时，您会发现不知道如何处理但并不希望经常发生的极端情况，最好的办法是收集更多信息，同时手动处理。罗马不是一天建成的，并且您的云服务在您打开它的第一天就无法完美运行。相反，当您遇到超时时，将其记录下来并保存下来，以备日后重新发送该电子邮件时使用。现在，假设您已经完成编码和集成测试，并且已经在生产环境中打开了服务。在第一天，您尝试发送100,000封电子邮件。如果您超时1000次，则说明确实发生了一些奇怪的事情，并且您知道您需要调查网络！相反，如果在第一天获得0次超时，第二天相同，然后在第七天，那么一周的700,000次尝试中只有1次超时怎么办？如果合适，您可以尝试致电该一位客户并说：“您好，抱歉打扰您，但我们确实致力于可靠性，并且遇到了技术问题。我想确保您收到[XYZ]的电子邮件收据。 ” 如果他们说不，那么回去更改代码可能很有意义，以便在出现超时时，您只需等待几秒钟即可重试，因为您知道它可能会起作用。两者之间的任何事情都相同。这里的重点是您将把人类的智慧运用到这个谜上。我发现不尝试超越未知通常更容易。只是设置自己以能够处理所有发生的事情，并弄清楚什么才是明智的事情，当您知道问题的实质是什么时。（您可能会喜欢别人写的这篇博客文章，主题是“不处理极端情况”。

编辑

登录后才能参与评论