在构建基于 Web 的 IMAP 客户端时,我应该让 Web 服务器直接与 IMAP 服务器对话,还是应该在中间有一个数据库,以便在需要时同步?
3 回答
您提出这个问题的事实意味着您担心 webmail 前端无法与 IMAP 后端一起有效地工作。我能想到几个原因,如果我错了,请纠正我:
- webmail 客户端是无状态的,会在 IMAP 服务器上进行大量调用,其中很多调用本质上是重复的(例如,当用户刷新屏幕时)。您担心来电的数量以及其中大多数的绝对不必要的性质会:
- 压倒 IMAP 服务器,或
- 向第三方 IMAP 提供商收取大量网络/数据/SLA 账单,或
- 比直接访问数据库要慢得多
- IMAP 服务器是外部的,有时可能对您的数据中心不可用,您需要确保网络邮件客户端继续为您的客户提供服务。
需要做出一个关键的决策点,但我认为这取决于您需要连接的 IMAP 服务器是在您的组织内部还是外部。
- 内部:
- Webmail 组件的性能可能会因 IMAP 服务器的延迟而受到影响
- 外部:
- 网络带宽或IMAP 使用成本高昂
- 性能同上
- 您需要在主 IMAP 服务器离线时镜像邮件数据。
在这种背景下,您正在考虑是否可以不使用数据库,因为您知道添加该层将是:
- 昂贵的
- 大大增加项目时间表(用于设计、开发和测试)
- 增加项目的技术和交付风险,并
- 添加一个您可能没有的主要架构组件。
内部 IMAP 服务器 - 性能
首先,对系统进行基准测试以查看性能是否真的受到影响可能是个好主意。我的直觉告诉我不一定要有,因为那里有许多响应迅速的网络邮件系统。
首先,有许多非常好的 IMAP 代理服务器可以让您保持 IMAP 连接有效,从而大大减少延迟。示例包括:
其次,如果您将 IMAP 服务器和 webmail Web 应用程序视为一个系统,那么您不将 IMAP 数据缓存在另一个数据库中可能是有意义的。您将从 IMAP 服务器引入数据延迟到您的数据库,遇到数据和数据库管理难题,并引入具有许多新故障点的系统复杂性。
相反,您可以优化您的 IMAP 服务器以与 webmail 应用程序一起使用吗?这可能涉及购买额外的服务器或升级您当前的服务器 - 但同时,您的网络邮件服务器会小得多,您不必为它购买数据库服务器。
IMAP 服务器几乎可以肯定具有内部缓存以提高性能,并且几乎可以肯定使用数据库(具有自己的缓存等)——许多人多年来对其进行了调整和调试。你可以利用这种经验和成熟度。
让我们想象一个假设的问题——系统变大并开始出现性能问题。使用自定义 DB 表调整和扩展自定义应用程序更容易,还是使用可用的商业支持和经过测试的良好文档更容易扩展广泛使用的商业或开源 IMAP 服务器?
外部 IMAP 服务器 - 最小化流量并最大化性能
考虑到这一点,目标是尽量减少 IMAP 协议调用,因为它们在时间(网络延迟)或金钱上是昂贵的。
首先,您可以使用 IMAPProxy(如上所述)来确保连接保持活动状态并且用户登录。
此外,我认为您需要使用数据库,但需要以缓存模式而不是完整数据模型。例如,您可以使用 NoSQL 数据库(键值或对象数据库)而不是 SQL 数据库:
- 存储对象(消息、文件夹元数据、附件等)而不是非规范化数据
- 可能不需要 ACID 行为 - 它是一个缓存
- 大多数按对象 id 或类查找,而不是按复杂的 WHERE 子句
以这种方式实施将使任务非常针对用例或用户故事,降低成本和风险,并使系统更具可测试性。如果您的实现中存在严重问题,则可以刷新整个缓存并恢复服务。
数据和数据库管理也将容易得多,并且不会存储完整的用户邮箱。
外部 IMAP 服务器 - 断开连接的模型
这假定您正在为外部 IMAP 服务提供 webmail 客户端,并且您知道外部 IMAP 服务会定期离线,但您仍然需要向用户提供电子邮件。
在这里,您显然需要在本地数据库中镜像用户的电子邮件。我建议您查看具有本地 IMAP 服务器并使用许多开源 IMAP 同步工具中的任何一个来镜像第三方 IMAP 服务器的架构解决方案。这里的好处是:
- 对于您的 webmail 应用程序,本地 IMAP 服务器看起来与任何其他简化 webmail 客户端的 IMAP 服务器完全相同
- 对于许多极端情况,同步是一个棘手的问题;这些都已经解决了
- 通过拥有完整的本地 IMAP 服务器,您可以拥有一个完全可管理的组件,并提供可选支持而无需开发成本
- 您可以让一些用户直接连接到外部 IMAP 服务器,而另一些用户则使用这种架构连接到缓存的服务器——这只是一个 URL
缺点是:
- 存储重复电子邮件的潜在成本巨大
- 用户查看新电子邮件的时间滞后,因为必须先在外部 IMAP 服务器上检测到它们,然后再在本地检测到它们。
您可以在本地使用许多 IMAP 服务器之一,对于同步,这里有一些可能性:
(免责声明:我自己没有使用过这些工具)
这完全取决于要求、要提供的服务的重要性以及您拥有的时间;-)
我见过雅虎、rediffmail IMAP 的案例,其中邮件在我的黑莓上随机重新下载。(供您参考。黑莓邮件服务首先将所有邮件从 IMAP 服务器下载到自己的服务器,然后将其分发到设备。)
使用中间件是个好主意,因为它可以减少任何与服务器相关的问题,例如邮件获取错误、随机错误或服务器崩溃。即使目标 IMAP 服务器已关闭,即使与邮件相关的活动也会更快,例如邮件读取、删除、移动到不同的文件夹可以更方便地处理。
我认为用户将从数据库方法中受益匪浅,并且也许可以通过限制存储在数据库中的最近消息的数量来降低存储成本。这将为用户提供快速的初始加载,这样他们就可以进入、阅读最新的电子邮件并退出,而无需等待 IMAP 服务器同步。数据库方法也可能是解决文件夹问题的方法,因为您可以缓存上次连接时下载的内容,然后在后台更新,防止用户等待服务器同步。简而言之,用户会更喜欢数据库方法,这才是最重要的。