Как избежать двойной отправки в Amazon SES?

Я отправляю электронные письма с Amazon SES, и мне интересно, как правильно обрабатывать повторные попытки в случае сбоя.

скажем, я выпускаю POST запрос SendEmail действия, но получите тайм-аут. Нет никакого способа узнать, было ли отправлено сообщение или нет.

можно ли отправить уникальный идентификатор с каждым письмом, поэтому я могу безопасно повторить попытку отправить это письмо, и пусть SES либо отправит письмо, либо скажет мне, что оно уже отправлено?

или в противном случае я должен выбрать, в случае сетевой ошибки, между риском отправить письмо дважды, и не отправлять письмо вообще.

1 ответов


по словам SES API Reference для SendRawEmail единственными параметрами, которые вы предоставляете как часть запроса, являются список получателей, тело электронной почты и ваш адрес источника. К сожалению, кажется очень ясным, что если вы получаете тайм-аут, а не ответ от SES, есть не так чтобы узнать, было ли отправлено это конкретное письмо. Я знаю, это очень расстраивает. Я тоже ненавижу, когда нахожусь в такой ситуации.

вы do, однако, некоторые варианты, когда дело доходит до выяснения наиболее практичным решением этой дилеммы. Вы можете принять общее решение никогда не повторять попытку и предположить, что Неотправленное сообщение лучше, чем дубликат сообщения. Вы также можете принять общее решение о том, что дубликаты писем полностью приемлемы. Однако мой предпочтительный и рекомендуемый подход-это менее академически удовлетворительная, но прагматичная середина. Позвольте мне объяснить.

при интеграции с новой службой, и вы найдете край если вы не знаете, как обращаться, но вы не ожидаете, что это произойдет очень часто, лучше всего собрать больше информации и обрабатывать вещи вручную в то же время. Рим не был построен за один день, и ваш облачный сервис не будет работать идеально в первый же день, когда вы его включите. Вместо этого, когда вы получите тайм-аут, войдите в него и сохраните все, что вам может понадобиться, чтобы отправить это письмо позже.

теперь представьте, что вы закончили кодирование и тестирование интеграции, и вы включили обслуживание в производстве. В первый день вы пытаетесь отправить 100 000 писем. Если вы получаете 1000 тайм-аутов, что-то действительно странное происходит, и вы знаете, что вам нужно исследовать свою сеть! Что делать, если вместо этого в первый день Вы получаете 0 тайм-аутов, то же самое на второй день, а затем на седьмой день, из 700 000 попыток в течение недели, был только 1 тайм-аут. Если необходимо, вы можете попробовать позвонить этому клиенту 1 и сказать: "Привет, извините за беспокойство, но мы действительно привержены надежности, и у нас был техническая проблема. Я хотел убедиться, что вы получили электронное письмо для [XYZ].- Если они скажут "нет", Что ж, тогда, возможно, имеет смысл вернуться и изменить код, чтобы, когда есть тайм-аут, вы просто повторили попытку, подождав несколько секунд, так как вы знаете, что это, вероятно, сработает. Идея что-нибудь между ними.

дело в том, что вы будете применять свой человеческий разум к тайне. Я обнаружил, что часто легче не пытаться перехитрить неизвестное. Просто настроить себя быть в состоянии справиться с тем, что происходит, и выяснить, что разумно делать, когда вы знаете, как на самом деле выглядит проблема.

(вы можете наслаждаться этим блоге -- написано кем-то другим -- о "не обработке краевых случаев".)