0

我需要为一个预计每小时发送 20 或 30 封电子邮件的中型项目处理电子邮件。

我在其他项目中设计了一个解决方案，它使用一个数据库表和一个每 5 或 10 分钟运行一次的 cronjob 来处理这个问题。数据库表非常简单。看起来像这样：

CREATE TABLE "atem_emails_envios" (
    "id_email_envio" int4 NOT NULL,
    "id_email_msg" varchar(20) NOT NULL,
    "dat_inserted" timestamp NOT NULL,
    "dat_sended" timestamp,
    "try_number" int4,
    "max_tries" int4 NOT NULL,
    "email_from" varchar(500) NOT NULL,
    "email_to" varchar(500) NOT NULL,
    "email_cc" varchar(500),
    "email_bcc" varchar(500),
    "email_subject" varchar(500) NOT NULL,
    "email_msg" text NOT NULL,
    "error_msg" text,
    "i_started" timestamp,
    "pid" int4,
    "coment" varchar(2000),
    "id_utiliz_ins" varchar(45),
    "id_utiliz_upd" varchar(45),
    "data_ult_actual" timestamp,
  PRIMARY KEY("id_email_envio"),
  CONSTRAINT "Ref_atem_emails_envios_to_atem_mensagens_email" FOREIGN KEY ("id_email_msg")
    REFERENCES "atem_mensagens_email"("id_email_msg")
    MATCH SIMPLE
    ON DELETE NO ACTION
    ON UPDATE NO ACTION
    NOT DEFERRABLE
);

处理电子邮件时，我只是将 PID 存储到表中以避免冲突。

我的问题朝着这个方向发展。我一直在使用此表来处理流量较低的网站中的电子邮件，并且效果很好。使用像 Celery 这样的队列管理器和像 RabbitMQ 这样的代理有什么优势？在我看来，我将增加另一层复杂性。使用像 Celery/RabbitMQ 这样的解决方案我会获得什么好处？

请给我一些线索。

此致，

4

1 回答 1

0

就像那句古老的格言“它没有坏，不要修理它”。如果您不打算扩展或担心当前的 CRON/PG 设置，听起来您真的不需要使架构复杂化。

也就是说，使用像 Celery 这样的异步框架是有好处的。仅举几例：

  • 您很可能有未来可以利用异步系统的用例（SMS 发送、用户处理、集成、缓存预热、webhook 等）
  • 如果/当您扩展时更容易维护，因为它有据可查并且拥有庞大的社区
  • 更高的可见性和控制力

至于复杂性，我们构建了与 Celery 的集成，因此您可以用我们的云消息队列服务IronMQ替换代理。查看http://Iron.io/celery。这将通过替换 RabbitMQ 来帮助降低复杂性和代理故障点。

希望这可以帮助！

于 2013-02-15T23:53:30.003 回答