web-dev-qa-db-ja.com

メールをリアルタイムで送信するのではなく、キューに入れるのが常に最善の方法ですか？

メールをキューに入れるか、リアルタイムで送信するかを決定する必要がある場合、ユーザーがリクエストを送信するとすぐに送信するのではなく、キューに入れて1つずつ送信するのが常に最善の方法ですか。

メールは、マンドリルという外部サービスを使用して送信されます。当社のWebサイトで誰かが特定のフォームを送信するたびに、操作が成功したことを示す通知メールが送信されます。これらの「要求」は、別のチームによってバックオフィスで処理され、その後、別の電子メールが元の要求者に送信されます。

また、アプリケーション内にマーケティングメールシステムを構築する必要があります。

（マンドリルを使用しているため）電子メールをキューに入れるとは、非同期に送信するのではなく、サービスへのAPI呼び出しをキューに入れることです。電子メールの送信は瞬時ではないため、クライアントは、（beanstalkdのような）キューシステムで処理するのではなく、Mandrillからの応答を受信するまで待機します。

これが私の意味のコードサンプルです。

public function example($id)
{
    [...]

    $Mandrill = \App::make('mandrill');

    $message = $Mandrill->prepareEmail(
        [...]
    );

    $Mandrill->messages->send($message, false, null, null);
}

私たちはすぐにAPI要求を送信しますが、応答は即時ではないため、API応答を待機しているため、要求は停止します。つまり、real-time（それが多分正しい用語かどうかわからない）。

上記で示したのは、現在のアプリケーションのコードベースの一部です。私が求めているのは、APIリクエストがアイテムのキューを介して送信され、キューマネージャー（beanstalkdなど）がそれらを1つずつ処理するようにコードをリファクタリングする価値があるかどうかです舞台裏の別のリクエストで）。

architectureemailmessage-queue
4
GiamPy

電子メールはリアルタイムの保証付き配信ではないため、ブロックして送信することには明らかな利点はありません。ただし、実際にはそれほど単純ではなく、ブロッキングにはメリットがあります。

ブロッキングがアップストリームプロセスに悪影響を与える場合は、非同期/キューイング送信を使用してください。

送信の試みが簡単な方法で失敗した（SMTPが利用できない、SMTP認証が失敗したなど）ことを上流プロセスが認識する必要がある場合は、同期/ブロッキング送信を使用します。

私はデフォルトのアプローチとして非同期を使用し、障害をログに記録するか、上流プロセスまたは下流監視プロセスがサブスクライブして処理できる送信ステータス用の個別のキューを用意します。

1
Alain O'Dea