9

Web ベースの IMAP クライアントを構築する場合、Web サーバーが IMAP サーバーと直接通信するようにする必要がありますか?それとも、必要に応じて同期されるデータベースを中間に配置する必要がありますか?

4

3 に答える 3

7

あなたが質問をしているという事実は、ウェブメールのフロントエンドがIMAPバックエンドで効果的に機能しないことを心配していることを意味します。私はいくつかの理由を考えることができます、私が間違っているなら私を訂正してください：

  1. ステートレスであるWebメールクライアントは、IMAPサーバー上で多くの呼び出しを行い、それらの多くは基本的に繰り返されます（たとえば、ユーザーが画面を更新したとき）。あなたは、呼び出しの数、およびそれらのほとんどの厳密に不必要な性質が次のいずれかになることを懸念しています。
    1. IMAPサーバーを圧倒する、または
    2. サードパーティのIMAPプロバイダーで大規模なネットワーク/データ/SLAの請求書をまとめる、または
    3. 直接DBアクセスよりもはるかに遅い
  2. IMAPサーバーは外部にあり、データセンターで利用できない場合があります。Webメールクライアントが引き続き顧客にサービスを提供していることを確認する必要があります。

重要な決定ポイントを作成する必要がありますが、接続する必要のあるIMAPサーバーが組織の内部にあるか外部にあるかによって異なると思います。

  • 内部：
    1. Webメールコンポーネントのパフォーマンスは、IMAPサーバーへの遅延で低下する可能性があります
  • 外部：
    1. ネットワーク帯域幅またはIMAPの使用は、金銭的にコストがかかります
    2. 上記のパフォーマンス
    3. メインのIMAPサーバーがオフラインのときにメールデータをミラーリングする必要があります。

このような背景から、このレイヤーを追加すると次のようになることがわかっているため、データベースなしで逃げることができるかどうかを検討しています。

  1. 高価な
  2. プロジェクトのタイムラインに大幅に追加します（設計、開発、テスト用）
  3. プロジェクトに技術的リスクと配信リスクを追加し、
  4. 他の方法では行わない可能性のある主要なアーキテクチャコンポーネントを追加します。

内部IMAPサーバー-パフォーマンス

まず、システムのベンチマークを行って、実際にパフォーマンスが低下しているかどうかを確認することをお勧めします。応答性の高いウェブメールシステムがたくさんあるので、1つである必要はないと私の直感は言います。

まず、IMAP接続を維持して待ち時間を大幅に短縮できる非常に優れたIMAPプロキシサーバーがいくつかあります。例は次のとおりです。

次に、IMAPサーバーとWebメールWebアプリケーションをシステムとして見る場合、IMAPデータをさらに別のデータベースにキャッシュしないことはおそらく理にかなっています。IMAPサーバーからデータベースへのデータ遅延を導入し、データとデータベース管理の問題を抱え、多くの新しい障害点を伴うシステムの複雑さを導入します。

代わりに、Webメールアプリで使用するためにIMAPサーバーを最適化できますか？これには、追加のサーバーの購入や現在のサーバーのアップグレードが含まれる場合がありますが、同時に、Webメールサーバーははるかに小さくなり、データベースサーバーを購入する必要はありません。

IMAPサーバーには、ほぼ確実にパフォーマンスのための内部キャッシュがあり、ほぼ確実にデータベースを使用します（独自のキャッシュなどを使用）。これは、長年にわたって多くの手によって調整およびデバッグされています。あなたはその経験と成熟度を使うことができます。

架空の問題を想像してみましょう。システムが大きくなり、パフォーマンスの問題が発生し始めます。カスタムDBテーブルを使用してカスタムアプリケーションを調整およびスケーリングする方が簡単ですか、それとも、商用サポートが利用可能でテスト済みの優れたドキュメントを使用して、広く使用されている商用またはオープンソースのIMAPサーバーをスケーリングする方が簡単ですか？

外部IMAPサーバー-トラフィックを最小化し、パフォーマンスを最大化

この懸念から、IMAPプロトコル呼び出しは時間（ネットワーク遅延）または費用がかかるため、最小限に抑えることが目的です。

まず、（上記のように）IMAPProxyを使用して、接続を維持し、ユーザーがログインしていることを確認できます。

さらに、データベースを使用する必要がありますが、完全なデータモデルではなくキャッシュのモードで使用する必要があると私は主張します。たとえば、SQLDBではなくNoSQLDB（Key-Valueまたはオブジェクトデータベース）を使用できます。

  • 非正規化されたデータではなく、オブジェクト（メッセージ、フォルダーメタデータ、添付ファイルなど）を保存します
  • ACIDの動作はおそらく必要ありません-それはキャッシュです
  • 複雑なWHERE句ではなく、オブジェクトIDまたはクラスによるほとんどのルックアップ

このように実装すると、タスクが非常にユースケースまたはユーザーストーリーに固有になり、コストとリスクが軽減され、システムのテストが容易になります。実装に重大な問題がある場合は、キャッシュ全体をフラッシュしてサービスを復元できます。

データとデータベースの管理もはるかに簡単になり、ユーザーのメールボックス全体が保存されることはありません。

外部IMAPサーバー-切断されたモデル

これは、外部IMAPサービスにWebメールクライアントを提供していることを前提としており、外部IMAPサービスがオフラインになることを定期的に知っていますが、それでもユーザーに電子メールを提供する必要があります。

ここでは、明らかにユーザーの電子メールをローカルデータベースにミラーリングする必要があります。ローカルIMAPサーバーがあり、多くのオープンソースIMAP同期ツールのいずれかを使用してサードパーティのIMAPサーバーをミラーリングするアーキテクチャソリューションを検討することをお勧めします。ここでの利点は次のとおりです。

  1. ウェブメールアプリから見ると、ローカルIMAPサーバーは他のIMAPサーバーとまったく同じように見え、ウェブメールクライアントを簡素化します。
  2. 同期は、多くのエッジケースで難しい問題です。これらはすべて以前に解決されています
  3. 完全なローカルIMAPサーバーを使用することで、開発コストなしでオプションのサポートを備えた完全に管理可能なコンポーネントを利用できます。
  4. 一部のユーザーは外部IMAPサーバーに直接接続し、一部のユーザーはこのアーキテクチャを使用してキャッシュされたサーバーに接続できます。これは単なるURLです。

欠点は次のとおりです。

  • 重複する電子メールの保存に莫大な費用がかかる可能性があります
  • 新しい電子メールは最初に外部IMAPサーバーで検出され、次にローカルで検出される必要があるため、ユーザーが新しい電子メールを表示するのに時間がかかります。

多くのIMAPサーバーの1つをローカルで使用できます。同期のために、いくつかの可能性があります。

（免責事項：私はこれらのツールを自分で使用していません）

于 2013-02-25T07:04:36.617 に答える
2

これは、要件、提供されるサービスの重要性、およびあなたが持っている時間に完全に依存します;-)

yahoo, rediffmail IMAP を使用して、ブラックベリーでランダムなタイミングでメールが再ダウンロードされるケースを見てきました (参考までに、ブラックベリー メール サービスは、最初にすべてのメールを IMAP サーバーから独自のサーバーにダウンロードしてから、デバイスに配布します)。

メール フェッチ エラー、ランダムなバグ、サーバー クラッシュなどのサーバー関連の問題を軽減できるため、中間ファイルを使用することをお勧めします。宛先の IMAP サーバーがダウンしていても、メールの読み取り、削除、別のフォルダーへの移動などのメール関連のアクティビティでさえ、より便利に処理できます。

于 2013-02-18T05:22:18.457 に答える
1

ユーザーはデータベース アプローチから大きなメリットを得られると思います。また、データベースに保存される最近のメッセージの数を制限することで、おそらくストレージ コストを削減できると思います。これにより、ユーザーは迅速な初期ロードを提供されるため、IMAP サーバーの同期を待たずに、アクセスして最新の電子メールを読み、終了することができます。データベースのアプローチは、前回接続したときにダウンロードしたものをキャッシュし、バックグラウンドで更新して、ユーザーがサーバーの同期を待つのを防ぐことができるため、フォルダーの問題の解決策になる可能性があります. 要するに、ユーザーはデータベース アプローチに満足し、それが重要なのです。

于 2013-02-23T05:09:51.237 に答える