在弹性应用程序设计上，eBay为什么选择MongoDB？

作为世界前十十个全球零售品牌，拥有1.7亿活跃买家和10亿在线市场，eBay无法承受系统停机带来的损失。这就是为什么公司依靠MongoDB作为其核心企业数据平台标准之一，为运行ebay.com的多个面向客户的应用程序提供支持。

在今年的MongoDB全球大会上，eBay的首席NoSQL DBA曲峰提供了弹性应用程序的实用设计模式 — 他的团队开发的一套支持企业级MongoDB部署的架构蓝图。

曲先生开始讨论多年来可用性概念的变化。过去，网站可以接受每周维护的预定停机时间。随着当前服务的全球化，用户或业务都不会接受如此频繁的停机!此外，大多数公司现在在商业硬件平台上构建其服务，而不是以前的 Sun Solaris / Sparc服务器。虽然商业硬件的成本要低得多，但是它也经常故障。

这两个因素从根本上改变了工程团队如何考虑可用性，并且引导eBay创建其“弹性设计模式”，以建立最大化平均故障时间(Mean Time To Failure，MTTF)并最大限度地减少平均恢复时间(Mean Time To Recovery，MTTR)的数据库最佳实践。

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

eBay目前运行超过3000个非关系型数据库实例，为一系列应用程序提供支持，可在其间管理数PB数据。在过去，Oracle是“记录系统”，而非关系型数据库则处理“参与系统”中使用的临时数据。然而，非关系型数据库环境已经成熟。通过一致的时间点备份和恢复，MongoDB现在也在eBay上服务于记录系统的用例。

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

曲先生介绍了eBay的“MongoDB弹性设计模式”，如图1所示。

图1：MongoDB恢复架构的eBay设计模式(图片由eBay的MongoDB世界大会演示提供)

在这种设计模式中，一个7节点的MongoDB副本集遍布eBay的三个美国数据中心。此模式可确保在主数据中心发生故障的情况下，数据库集群可以通过在剩余的数据中心之间建立一个仲裁来保持可用性。MongoDB的副本集成员可以被分配选举优先级，以控制哪些Slave成员被认为是在Primary成员失败时的晋升候选人。例如，如果副本集Primary成员失败，则DC1本地的节点将被优先选择。只有整个DC1遭受中断，DC2中的复制集成员才会被认为可以进行选举，根据哪个节点已经执行最近的写操作选择新的Primary成员。可以通过使用MongoDB的 majority write concern来扩展这种设计模式，以使得能够跨数据中心持久的写入。

标准MongoDB设计模式被用作eBay的“阅读强化/高可用读取模式”的基础，该演示文稿用于为eBay产品目录提供支持。对于目录负载，MongoDB副本集可以扩展到50个成员，为大并发量的数据分发提供了读取的可扩展性和恢复能力。

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

图2：MongoDB极高读/写模式的eBay设计模式(图片由eBay的MongoDB世界演示提供)

其次，eBay开发人员可以使用特定的MongoDB写入和读取配置来设计模式，以调整最佳满足不同应用需求的持久性和一致性级别。

曲先生指出，随着近期的产品功能增多，MongoDB正在越来越满足更广泛的应用需求：