我通常发送交易电子邮件以回应我网站上的某些操作，其中一些我延迟发送几个小时。实际对电子邮件进行排队的功能是使用.delay()调用的Celery任务函数，该函数最终使用djrill向Mandrill进行API调用。
我发现Mandrill在发送电子邮件时会提供send_at参数，该电子邮件会让Mandrill延迟发送电子邮件直到指定时间。在任务上调用apply_async() or delay()时，Celery还会提供eta或countdown个参数，这将使Celery工作人员在执行任务之前等待X个时间 - 这里的数量相同的事情。
忽略成本，这种方法在架构上更可取 - 让Celery延迟使用countdown对电子邮件进行排队，或者立即将电子邮件发送到Mandrill，但是send_at参数让Mandrill等我？做出这个决定时我应该考虑哪些因素？
答案 0 :(得分：0)
我会在这里分享一些我们可以考虑的要点：
容错：如果我们将此责任交给Celery，那么我们可能更容易失败，因为如果消息队列（Rabbitmq，ZeroMQ或其他），机器或者Celery本身失败，然后电子邮件永远不会被发送。 Mandrill也可能失败，但可能是次要成绩。
维护：如果您需要更改Celery的其他内容怎么办？在这种情况下，您需要迁移代码，并可能花一些时间来弄清楚如何在新的MQ工具中执行此调度。
OOP ：从OPP的角度来看，我们可能会将Mandrill视为发送电子邮件的实体，这会带来一些功能，例如：安排，所以让我们从我们的系统中使用这个外部服务，让它做它的工作！
可用性和可扩展性：考虑一下您需要在多台服务器上同时运行系统的假设情况，因为性能要求不断提高;这是处理此调度的更简单，更有效的方法吗？
这些不是应该考虑做出决定的所有方面，但肯定是一些不容错过的方面。希望有助于找到更好/更可靠的解决方案。