現在メールを送信する Web アプリケーションがあります。Web アプリケーションが電子メールを送信するときに (電子メールの送信はユーザー アクションに基づいており、自動ではありません)、ファイルの圧縮などの他のプロセスを実行する必要があります。
私は自分のアプリケーションを「将来の証明」にしようとしています。そのため、多数のユーザーがいる場合、サーバーに負担をかけたくないので、送信する必要がある電子メールと圧縮する必要があるファイルを配置することを考えました列に並んでいます。それらをテーブルに入れ、cron ジョブを使用して毎秒チェックし、実行します (一度に x 行)。
上記は良い考えですか？または、より良いアプローチがありますか？後で頭痛の種を避けるために、これを適切に行うには本当に助けが必要です:)
皆さんありがとう
これは良いアプローチですが、今できる最も重要なことは、メッセージをキューに入れるための明確なインターフェイスと、キューを消費するためのインターフェイスを用意することです。いずれかの側で使用法を DB にハードコーディングしないでください。
後でこれがボトルネックになった場合は、DB にアクセスすることさえできない別のマシンからメール送信を行いたいと思うかもしれません。
無視している側面の 1 つは、使用している圧縮速度です。圧縮レベルを軽くすると、圧縮時間が大幅に短縮され (簡単に 2 倍になります)、合計すると複数のユーザーの領域に入ると、多くのことが起こります。
圧縮をインテリジェントにし、既に圧縮されている大きなファイル (MP3、ZIP、DOCX、XLSX、JPG、GIF など) を圧縮する場合は圧縮を使用せず、単純なテキスト ファイル (TXT、XML) がある場合は高圧縮を使用すると、さらに効果的です。 、DOC、XLS など) は、圧縮率が高くても非常に高速に圧縮されるためです。
うーん。cronが毎秒何かを実行するというアイデアは本当に好きではありません。それはあまりにも頻繁に思えます。アプリケーションが本当に応答性が必要な場合は、同期を維持する必要があると思います。つまり、Webアプリケーションでの処理を維持し、サーバーの負荷レベルを低く抑えるための他の方法を探します。
チェックの間隔が長くなる場合は、cronジョブで一度に1つのアイテムのキューをチェックすることをお勧めします。存在する場合は、それを処理してから、終了せずに次のものを再度確認します。ない場合は、終了して5分ほど再試行しないでください。
ただし、そうは言っても、適切なメール転送エージェント（sendmail、postfix、Exchange）にはキューイングが組み込まれています。予期しないことが起こったときに確実に配達が行われるようにするよりも、おそらくそれはあなたができるよりも良い仕事をするでしょう。キューに入れられた電子メールの処理については、考慮すべきことがたくさんあります。私は通常、プロセスのできるだけ早い段階でアウトバウンド電子メールをMTAに渡すことを好みます。
--bmb _
分散キューイングを行うものを組み込みます。ボリュームをスケーリングすると、ボトルネックが発生する可能性のあるティアのさまざまなレイヤーをスケーリングできます。
cronを毎秒実行する理由はありますか？音量はそんなに大きいですか？物事を入れ替えたり、注意を引くためにビットをリファクタリングしたりするので、n層の実装を維持するために最善を尽くします。
数週間は、設計したものを作成しないようにしてください。多くの場合、物事が閉じ込められる前に、他のシナリオが発生します。
良いアプローチ。いくつかの改良点：
私の経験では、これはうまくスケーリングします。
重要な点は、cron ジョブを 1 秒ごとに実行するのではなく、終了時に自動的に再起動される常時実行のデーモンを用意することです。
理由の 1 つは、ご自身で説明されているように、多くのユーザーがメールの送信を要求し、キューが蓄積された場合、1 つの cronjob が ext one stats の前に終了する時間がなく、システムがフラッディングするリスクがあるためです。プロセスで。
上記は良い考えですか？はい
今後数百万人のユーザーを処理するためのより良いソリューションはありますか? おそらく..しかし、それは重要なことではありません。重要なのは、抽象化のレイヤーを構築していることです。いつか途方もないトラフィックが発生し、cron キューが追いつかない場合は、それを使用するコードを変更せずに、そのレイヤーの機能を置き換えることができます。