使用MongoDB构建任务关键型多数据中心应用程序

232次阅读

作为全球 10 大零售品牌，在全球 190 个市场拥有 170 多万活跃买家和 10 亿个实时列表，eBay 无法承受系统停机。这就是为什么该公司依赖 MongoDB 作为其核心企业数据平台标准之一，为运行 ebay.com 的多个面向客户的应用程序提供支持。

在今年的 MongoDB World 大会上，eBay 的首席 NoSQL DBA 曲峰展示了适用于弹性应用程序的实用设计模式——他的团队为支持企业级 MongoDB 部署而开发的一组架构蓝图。

曲先生开始了他的会议，讨论了这些年来可用性的概念是如何变化的。过去，站点为每周维护事件安排停机时间是可以接受的。随着当今服务的全球性，无论是用户还是企业，都不太接受！此外，大多数组织现在在商品硬件平台上构建他们的服务，而不是过去异国情调的 Sun Solaris / Sparc 服务器。虽然商品硬件的成本要低得多，但它也经常出现故障。这两个因素从根本上改变了工程团队考虑可用性的方式，并促使 eBay 创建其“弹性设计模式”来制定数据库最佳实践，以最大限度地提高平均故障时间 (MTTF) 并最大限度地减少平均恢复时间 (MTTR)。

为了构建他们的应用程序，eBay 开发人员可以从五种企业批准的数据库标准中进行选择。除了 MongoDB，团队还可以选择使用 Oracle 或 MySQL 关系数据库，以及两个 NoSQL 选项。曲先生的 DBA 团队提供有关选择适当数据库的指导，根据应用程序的数据访问模式、用户负载、数据类型等来确定选择。

eBay 目前运行着 3,000 多个非关系型数据库实例，支持一系列应用程序，管理它们之间的数 PB 数据。过去，Oracle 是记录系统，而非关系型数据库处理“参与系统”中使用的瞬态数据。然而，非关系数据库领域已经成熟。通过一致的时间点备份和恢复，MongoDB 现在还为 eBay 的记录系统用例提供服务。

虽然 eBay 的所有非关系数据库选择都提供内置的故障恢复能力，但它们做出了不同的设计权衡，可能会影响应用程序行为。DBA 团队从六个维度评估这些差异：可用性、一致性、持久性、可恢复性、可扩展性和性能。例如，那些使用点对点、无主设计的 NoSQL 数据库具有昂贵的数据修复和重新平衡过程，必须在节点故障后启动。此重新平衡过程会影响应用程序吞吐量和延迟，并且会在客户端等待恢复时导致连接堆叠，从而导致应用程序停机。为了减轻这些影响，eBay 不得不在这些无主数据库之上分层应用程序级分片解决方案，该解决方案最初是为其 Oracle 资产开发的。这种方法使 DBA 团队能够将较大的集群划分为一系列子集群，从而将重新平衡开销隔离到较小的节点集，仅影响查询的一个子集。eBay DBA 团队正是针对这些不同类型的数据库行为构建了其弹性设计模式。

曲先生介绍了eBay标准的“MongoDB Resilience Design Pattern”，如下图1所示。

MongoDB 弹性架构的 eBay 设计模式

图 1：eBay 的 MongoDB 弹性架构设计模式。（图片由 eBay 的 MongoDB World 介绍提供）

在这种设计模式中，一个 7 节点的MongoDB 副本集分布在 eBay 的三个美国数据中心。这种模式确保在主数据中心发生故障时，数据库集群可以通过在其余数据中心之间建立仲裁来保持可用性。可以为 MongoDB 的副本集成员分配选举优先级，以控制在主要失败的情况下哪些次要成员被视为晋升的候选人。例如，如果主副本集成员失败，则优先选择 DC1 本地的节点。只有当整个 DC1 发生中断时，才会考虑选择 DC2 中的副本集成员，并根据哪个节点提交了最近的写入操作来选择新的主要成员。这种设计模式可以通过使用MongoDB 的多数写入关注进行扩展启用跨数据中心持久写入。

标准 MongoDB 设计模式用作演示文稿中讨论的 eBay“读取密集/高可用读取模式”的基础，该模式用于支持 eBay 产品目录。对于目录工作负载，MongoDB 副本集扩展到 50 个成员，为读取可扩展性和弹性提供海量数据分布。

对于写入密集型的工作负载，eBay 开发了“极高的读/写模式”，该模式在其美国数据中心分布了一个分片的 MongoDB 集群。

MongoDB 极高读/写模式的 eBay 设计模式