电子邮件-使用定制解决方案或芹菜/RabbitMQ处理广告网站电子邮件？

我需要处理一个中型项目的电子邮件，预计每小时发送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存储到表中以避免冲突

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

请给我一些线索

致以最诚挚的问候，

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

也就是说，使用芹菜这样的异步框架有很多好处。举几个例子：

• 您很可能有未来的用例可以利用异步系统（SMS发送、用户处理、集成、缓存预热、Webhook等）
• 如果/当您扩展时更容易维护，因为它有很好的文档记录，并且有一个大型社区
• 更高的可视性和控制能力

至于复杂性，我们构建了与芹菜的集成，以便您可以用我们的云消息队列服务替换代理。退房通过替换RabbitMQ，这将有助于降低复杂性和代理故障点

希望这有帮助