Задержка отправки электронной почты с использованием Mandrill send_at или обратного отсчета сельдерея/eta

Question

Я обычно отправляю транзакционные письма в ответ на определенные действия на моем сайте, некоторые из которых я откладываю на пару часов. Функция, которая фактически ставит очередь на электронную почту, - это задача задачи Celery, вызываемая с .delay(), которая в конечном итоге вызывает вызов API Mandrill с использованием djrill.

Я обнаружил, что Mandrill предлагает параметр send_at при отправке сообщения электронной почты, на которое Mandrill задерживает отправку электронной почты до указанного времени. Сельдерей также предлагает eta или countdown параметров при вызове apply_async() or delay() по задаче, в которой рабочий из сельдерея будет ждать X времени до выполнения задачи —, которая здесь будет равна тому же.

Игнорирование стоимости, какой подход является архитектурно предпочтительным —, имеющий задержку сельдерей массового обслуживания электронной почты с помощью countdown или отправки электронной почты немедленно Mandrill, но с параметром send_at так Mandrill меня ждет? Какие факторы следует учитывать при принятии этого решения?

Answer 1

Я поделюсь некоторые моменты, мы могли бы во внимание, чтобы сделать выбор здесь:

1. Отказоустойчивость: если мы даем эту ответственность сельдерея, то мы могли бы быть более склонны к терпит неудачу, так как если очередь сообщений (Rabbitmq, ZeroMQ или что-то еще), сама машина или сам сельдерей терпят неудачу, сообщение электронной почты никогда не будет отправлено. Мандрилл тоже не мог справиться, но, вероятно, был в младшем классе.

2. Техническое обслуживание: А что, если вам нужно изменить сельдерей на что-то еще? В этом случае вам нужно перенести код и, возможно, потратить некоторое время, чтобы выяснить, как это сделать в новом инструменте MQ.

3. OOP: С точки зрения OPP мы можем видеть Mandrill как объект, который отправляет электронные письма, что приносит несколько функций, например. планирование, поэтому давайте использовать этот внешний сервис из нашей системы, пусть это сделает его работу!

4. Удобство и масштабируемость: Подумайте о гипотетической ситуации, когда вам необходимо запустить вашу систему на нескольких серверах одновременно из-за растущих требований к производительности; который является более простым и эффективным способом обработки этого планирования?

Это не все аспекты, которые следует учитывать при принятии решения, но, безусловно, некоторые из них не должны быть упущены. Надеюсь, что это поможет понять лучшее/твердое решение.