0

1時間に20〜30通のメールを送信することを期待している中規模のプロジェクトのメールを処理する必要があります。

他のプロジェクトで、データベーステーブルと5分または10分ごとに実行されるcronジョブを使用してこれを処理するソリューションを設計しました。データベーステーブルは非常に単純です。このように見えます：

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をテーブルに保存するだけです。

私の質問はこの方向に進んでいます。私はこのテーブルを使用して、トラフィックの少ないWebサイトで電子メールを処理しており、うまく機能しています。CeleryのようなキューマネージャーとRabbitMQのようなブローカーを使用することにはどのような利点がありますか？複雑さの層をもう1つ追加するように思えます。Celery / RabbitMQのようなソリューションを使用するとどのようなメリットがありますか？

手がかりを教えてください。

よろしくお願いします、

4

1 に答える 1

0

古い格言のように「壊れていないので、直さないでください」。スケーリングを計画していない場合や、現在のCRON / PGの設定について心配していない場合は、アーキテクチャを複雑にする必要があるようには思えません。

そうは言っても、Celeryのような非同期フレームワークを使用することには利点があります。いくつか例を挙げると：

  • 非同期システム（SMS送信、ユーザー処理、統合、キャッシュウォーミング、Webhookなど）を利用できる将来のユースケースがあるかもしれません。
  • 十分に文書化されており、大規模なコミュニティがあるため、スケーリングする場合は保守が容易です。
  • 可視性と制御性の向上

複雑さについては、Celeryとの統合を構築したため、ブローカーをクラウドメッセージキューサービスIronMQに置き換えることができます。http://Iron.io/celeryをチェックしてください。これにより、RabbitMQを置き換えることで、複雑さとブローカーの障害点を減らすことができます。

お役に立てれば！

于 2013-02-15T23:53:30.003 に答える