基于web的IMAP客户端是否应该有自己的数据库？ < P>当构建基于Web的IMAP客户端时，是否应该让Web服务器直接与IMAP服务器对话，或者在中间有一个数据库，在需要时同步？ < P>这完全取决于所提供的服务的要求、临界性和您所拥有的时间；p>

我在yahoo、RedifMail IMAP上看到过这样的案例，邮件在randon定时在我的黑莓手机上重新下载。（请参考。黑莓邮件服务首先将所有邮件从IMAP服务器下载到自己的服务器，然后将其分发到设备。）

---

使用中间层是一个好主意，因为它可以减少任何与服务器相关的问题，如邮件提取错误、随机错误或服务器崩溃。即使是与邮件相关的活动，如邮件阅读、删除、，即使目的地的IMAP服务器已关闭，也可以更方便地处理移动到不同的文件夹。

我认为用户将从数据库方法中受益匪浅，也许可以通过限制数据库中最近存储的邮件数量来降低存储成本。这将为用户提供一个快速的初始加载，这样他们就可以进入、阅读最新的电子邮件并离开，而无需等待IMAP服务器同步。数据库方法也可以解决文件夹问题，因为您可以缓存上次连接时下载的内容，然后在后台进行更新，以防止用户等待服务器同步。简言之，用户会更喜欢使用数据库方法，这才是最重要的。

您提出这个问题的事实意味着您担心webmail前端无法有效地与IMAP后端配合使用。我能想出几个理由，如果我错了，请纠正我：

webmail客户端是无状态的，它会在IMAP服务器上进行大量调用，其中许多调用基本上是重复的（例如当用户刷新屏幕时）。您担心的是，电话的数量，以及大多数电话的绝对不必要性，将：

覆盖IMAP服务器，或

向第三方IMAP提供商收取大额网络/数据/SLA账单，或

比直接数据库访问慢得多

IMAP服务器是外部的，有时可能对您的数据中心不可用，您需要确保webmail客户端继续向客户提供服务

需要做出一个关键的决策点，但我认为这取决于您需要连接的IMAP服务器是组织内部的还是外部的

• 内部：
• 网络邮件组件的性能可能会因IMAP服务器的延迟而受到影响
• 外部：
• 网络带宽或IMAP使用成本高昂
• 性能如上所述
• 当主IMAP服务器脱机时，您需要镜像邮件数据

在此背景下，您正在考虑是否可以不使用数据库，因为您知道添加此层将：

昂贵的

大大增加项目时间表（用于设计、开发和测试）

将技术和交付风险添加到项目和

添加一个主要的体系结构组件，否则您可能不需要它

内部IMAP服务器-性能

首先，对系统进行基准测试可能是一个好主意，看看是否真的有性能损失。我的直觉告诉我，不必有这样的系统，因为有很多响应速度很快的网络邮件系统

首先，有许多非常好的IMAP代理服务器使您能够保持IMAP连接的活动状态，从而大大减少延迟。例子包括：

其次，如果将IMAP服务器和webmail web应用程序视为一个系统，则不将IMAP数据缓存在另一个数据库中可能是有意义的。您将引入从IMAP服务器到数据库的数据延迟、数据和数据库管理难题，并引入系统复杂性和许多新的故障点

相反，您能否优化IMAP服务器以与webmail应用程序配合使用？这可能需要购买一台额外的服务器或升级您当前的服务器，但同时，您的webmail服务器将更小，您不必为此购买数据库服务器

IMAP服务器几乎肯定有内部缓存以提高性能，并且几乎肯定使用数据库（带有自己的缓存等）——多年来，许多人对其进行了调优和调试。你可以利用这种经验和成熟度

让我们设想一个假设的问题——系统变大并开始出现性能问题。使用自定义DB表调整和扩展自定义应用程序更容易，还是使用可用的商业支持和经过测试的良好文档更容易扩展广泛使用的商业或开源IMAP服务器

外部IMAP服务器-最小化流量并最大限度地提高性能

考虑到这一点，我们的目标是最小化IMAP协议调用，因为它们在时间（网络延迟）或金钱上都很昂贵

首先，您可以使用IMAPProxy（如上所述）确保连接保持活动状态，并确保用户登录

此外，我认为您需要使用数据库，但使用的是缓存模式，而不是完整的数据模型。例如，您可以使用NoSQL数据库（键值或对象数据库）而不是SQL数据库：

• 存储对象（邮件、文件夹、元数据、附件等），而不是非规范化数据
• 可能不需要ACID行为—它是一个缓存
• 大多数查找是按对象id或类进行的，而不是按复杂的WHERE子句进行的

以这种方式实施将使