0

1 秒あたり 30 ～ 100 通の電子メールを処理する必要がある自社開発の SMTP リレー サーバーに高可用性を実装する最善の方法は何かと考えています。

このサーバーが本質的に行うことは、さまざまな smtp クライアントで認証し、特定のメール サーバーにリレーしてエラーを処理することです。たとえば、メール サーバーが使用できないなどです。高可用性を実現するには、システムがクラスタリングをサポートしている必要があります。これにより、プライマリ/セカンダリ アクティブ クラスタに Windows クラスタリングを使用できます。

メールキューは次の場所にあると思います:

  1. メモリ (このメソッドは明らかな理由で廃止されました。)
  2. RDMS
  3. ファイル (これは IIS 仮想 SMTP が使用するものだと思いますか?)
  4. SQLiteなどの組み込みDB
  5. SQLite とファイルの混在
  6. インストールと構成が必要なサードパーティの奇抜なキュー製品はありますか?

高可用性を実現する通常の方法は、MySQL などの RDBMS を使用することですが、強力な MySQL サーバーがない限り、メッセージ キューに RDBMS を使用するとパフォーマンスが大幅に低下します。その上、簡単ではない MySQL クラスタリングを実装する必要があります。また、誰もMySQLをキューとして使用すべきではないことをどこかで読みました- http://www.engineyard.com/blog/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why -イットル-バイト-ユー/

あるいは、SQLite+File を使用することもできます。これはおそらく最速 (純粋なメモリ以外) で、展開が最も簡単な方法 (インストールするものは何もありません) ですが、SQLite のクラスタリングがないため、サーバーがクラッシュした場合、未送信のメッセージが残っている可能性があります。失った。

4

1 に答える 1

1

2 と 4 は同じもの - RDBMS です。RDBMS は複雑なクエリを対象としており、時間に合わせて維持する必要があるため、これは適切な選択ではありません。ガベージを収集し、インデックスを再構築し、db ファイルを大きくします...次の INSERT はいつでも遅くなるか、しばらくの間完全にブロックされることさえあります。Firebird や Postgress のようなバージョンベースのエンジンでも。MS SQL や SQLite のようなロックベースの場合はなおさらです。

信頼性を高めたい場合は、複数の狭いタスク ワーカーとして実装することをお勧めします。これにより、OmniThreaLibrary または AsyncCalls を使用したマルチスレッドの利点も得られます。

「シンク」ワーカーはメールをメモリ バッファに受信し、おそらくいくつかのメタデータ フォーム ヘッダーを抽出し、それを現在の受信キューに格納する必要があります。Win32 スレッドは高価なので、Erlang/Scala の「アクター」フレームワークのように、1 つのスレッドを一度に複数のソケットで動作させるとよいでしょう。クラッシュをローカライズするために、いくつかのスレッドを qmail のような別の exe に移動することもできます。そして将来的には、コンピューターのクラスター間でも。

「ダンパー」は分離されたキューを取り、それを連続した非 SQL ファイルにまとめます (HDD のスラッシング data-filesystem-data-filesystem-... のために個別のファイルは必要ありません)。その後、彼はキューを切り替えます。 : 前述の受信キューをダンプ用に分離し、空にしたばかりのキューに置き換えます。「2 つのキューを持ち、それらを切り替える」ことは、たとえば 3D ゲームで使用される一般的な「ページめくり」の特徴です。TForm.DoubleBuffering は似ていますが縮小された概念です。ところで、上記のメモリ内キューのように、これらのファイルを含む 2 つのフォルダーも必要です。

「dbkeeper」も同様に、ファイル ダンプの 1 つを取得し、それを RDBMS に移動して切り替えます。

これらの切り替えアクティビティに関して、これらのワーカー間の通信を設定する必要があります。各キューは受信またはダンプし、同時アクセスを最小限に抑えます (頻度と寿命の両方)。

mailinator の設計について読んでいるかもしれません。そのメンテナーは、1 つまたは別のボトルネックを踏んだ後、ソフトウェアを数回リファクタリングしました。これにより、これらのボトルネックがパフォーマンスに影響を与え始める時期を予測することもできます。

しかし、実際には、代わりに準備ができてテスト済みのサーバーを使用してみませんか?

于 2012-10-01T10:28:43.660 に答える