【问题标题】:Should a web based IMAP client have its own database?基于 Web 的 IMAP 客户端是否应该有自己的数据库?
【发布时间】:2013-02-01 02:52:15
【问题描述】:

在构建基于 Web 的 IMAP 客户端时,我应该让 Web 服务器直接与 IMAP 服务器对话,还是应该在中间有一个在需要时同步的数据库?

【问题讨论】:

  • 至少有一个存储消息头的数据库;根据我的经验,从 IMAP 服务器获取标头的性能还有很多不足之处。还允许用户在不访问 IMAP 服务器的情况下执行搜索(如果您只在数据库中存储标头,则除了邮件正文搜索之外)。

标签: web imap


【解决方案1】:

您提出这个问题的事实意味着您担心网络邮件前端无法与 IMAP 后端一起有效地工作。我能想到几个原因,如果我错了,请纠正我:

  1. webmail 客户端是无状态的,会在 IMAP 服务器上进行很多 次调用,其中很多会本质上是重复的(例如,当用户刷新屏幕时)。您担心来电的数量以及其中大多数的绝对不必要的性质会:
    1. 使 IMAP 服务器不堪重负,或
    2. 向第三方 IMAP 提供商收取大量网络/数据/SLA 账单,或
    3. 比直接访问数据库要慢得多
  2. IMAP 服务器是外部的,有时可能对您的数据中心不可用,您需要确保网络邮件客户端继续为您的客户提供服务。

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

  • 内部
    1. 网络邮件组件的性能可能会因 IMAP 服务器延迟而受到影响
  • 外部
    1. 网络带宽IMAP使用成本高昂
    2. 性能同上
    3. 您需要在主 IMAP 服务器离线时镜像邮件数据。

在这种背景下,您正在考虑是否可以不使用数据库,因为您知道添加这一层将是:

  1. 昂贵
  2. 大大增加项目时间表(用于设计、开发和测试)
  3. 给项目增加了技术和交付风险,并且
  4. 添加一个您可能没有的主要架构组件。

内部 IMAP 服务器 - 性能

首先,对系统进行基准测试以查看性能是否真的受到影响可能是个好主意。我的直觉告诉我不一定要有,因为市面上有很多响应速度非常快的网络邮件系统。

首先,有许多非常好的 IMAP 代理服务器可以让您保持 IMAP 连接有效,从而大大减少延迟。示例包括:

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

相反,您可以优化您的 IMAP 服务器以与网络邮件应用程序一起使用吗?这可能涉及购买额外的服务器或升级您当前的服务器 - 但与此同时,您的网络邮件服务器会小得多,您不必为它购买数据库服务器。

几乎可以肯定,IMAP 服务器具有内部缓存以提高性能,并且几乎可以肯定使用数据库(具有自己的缓存等)- 许多人多年来对其进行了调整和调试。您可以利用这种经验和成熟度。

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

外部 IMAP 服务器 - 最小化流量和最大化性能

考虑到这一点,我们的目标是尽量减少 IMAP 协议调用,因为它们在时间(网络延迟)或金钱方面是昂贵的。

首先,您可以使用 IMAPProxy(如上所述)来确保连接保持活跃并且用户登录。

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

  • 存储对象(消息、文件夹元数据、附件等)而不是非规范化数据
  • 可能不需要 ACID 行为 - 它是一个缓存
  • 大多数查找是按对象 ID 或类,而不是复杂的 WHERE 子句

以这种方式实施将使任务非常针对用例或用户故事,降低成本和风险,并使系统更具可测试性。如果您的实现中出现严重问题,可以刷新整个缓存并恢复服务。

数据和数据库管理也会轻松很多,不会存储完整用户的邮箱。

外部 IMAP 服务器 - 断开连接的模型

这假设您正在为外部 IMAP 服务提供 webmail 客户端,并且您知道外部 IMAP 服务会定期离线,但您仍需要向用户提供电子邮件。

在这里,您显然需要在本地数据库中镜像用户的电子邮件。我建议您查看具有本地 IMAP 服务器并使用许多开源 IMAP 同步工具中的任何一个来镜像第三方 IMAP 服务器的架构解决方案。这里的好处是:

  1. 对于您的网络邮件应用程序,本地 IMAP 服务器看起来与任何其他 IMAP 服务器完全相同简化了网络邮件客户端
  2. 对于许多边缘情况,同步是一个棘手的问题;这些都已经解决了
  3. 通过拥有完整的本地 IMAP 服务器,您可以拥有一个完全可管理的组件,并提供可选支持,而无需开发成本
  4. 您可以让一些用户直接连接到外部 IMAP 服务器,而另一些用户则使用这种架构连接到缓存的服务器 - 这只是一个 URL

缺点是:

  • 存储重复电子邮件可能会产生巨大的成本
  • 用户查看新电子邮件的时间过长,因为必须先在外部 IMAP 服务器上检测到它们,然后再在本地检测到。

您可以在本地使用多个 IMAP 服务器之一,对于同步,这里有一些可能性:

免责声明:我自己没有使用过这些工具)

【讨论】:

    【解决方案2】:

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

    【讨论】:

      【解决方案3】:

      这完全取决于要求、要提供的服务的重要性以及您拥有的时间;-)

      我看到了 yahoo, rediffmail IMAP 的案例,其中邮件在随机时间重新下载到我的黑莓上。(供您参考。黑莓邮件服务首先将所有邮件从 IMAP 服务器下载到自己的服务器,然后将其分发到设备。)

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

      【讨论】:

      • 问题比这复杂一点。同步实际消息并不是真正的问题,因为我可以使用 UID 来确保网站 + 其他客户端同步。问题是文件夹没有 UID,似乎每次都必须下载它们,这可能很耗时。 (在 SO 上按 Enter 触发帖子,这是愚蠢的 UX,继续:)在 imap 文件夹和数据库上复制消息对我来说似乎是错误的,特别是因为存储成本会飙升。
      • 我同意将所有消息从 imap 复制到数据库不是一个好主意。但是,在数据库上缓存最近的消息并没有错。您可能希望在数据库中创建一个索引,以便您的 web imap 客户端可以更好更快地进行搜索。
      猜你喜欢
      • 2017-11-27
      • 1970-01-01
      • 2011-02-13
      • 2013-11-29
      • 2021-12-11
      • 2015-05-17
      • 1970-01-01
      • 2020-05-26
      • 2014-10-20
      相关资源
      最近更新 更多