易趣：使用MongoDB创建关键业务的多数据中心应用

eBay：使用MongoDB创建关键业务的多数据中心应用

作为全球前十的零售品牌，eBay的活跃用户有一亿七千多万，并拥有跨越全世界190个市场的10亿购物清单，这样的规模下，eBay绝对不允许出现宕机的情况。这也就是为什么公司会依赖于MongoDB提供企业级平台标准以及面向用户的应用。

在今年的MongoDB World conference大会上，eBay的首席NoSQL DBA，Feng Qu，为大家展示了他以及他的团队开发的用来支持企业级MongoDB部署的一整套架构—弹性应用的实用设计模式。

Qu先生首先探讨了“可用性”这个概念在最近几年的变化。在过去，网址进行周期性的定时停服维护是正常的，但是，最近几年，随着如今服务的全球化，用户以及企业都不再接受这样的停服操作。除此之外，大部分组织机构把他们的服务部署在商业硬件平台而不是之前的Sun Solaris / Sparc。商业硬件相对更加便宜，但是出现问题的频率也相对较高。这些因素都实质上影响着软件团队对可用性的看法。这也eBay要创建“弹性设计模式”的初衷，就是要创建最佳的数据库系统可以最大化平均失效时间（MTTF）同时最小化平均恢复时间（MTTR）。

开发人员创建应用的时候可以选择五种企业认可的数据库标准。除了MongoDB，还可以选择oracle和MySQL这样的关系型数据库以及另外两种nosql数据库系统。Qu先生的团队会为他们的选择提一些意见，保证所选的数据库系统可以支撑数据读取模式、用户压力等等。

eBay目前运行着3000多非关系型数据库实例，支撑着大量应用以及应用之间PB级别的数据传输。在过去，oracle是记录系统，非关系型数据库只维护一些临时数据，现在非关系型数据库的场景已经成熟，不仅拥有一致性、具体到点的备份以及及时恢复性，MongoDB在eBay中的有些场景中也可作为记录系统。

尽管eBay的非关系型数据库提供内置的故障弹性，他们也可以选择不同的设计权衡来影响应用的表现。DBA在选择时主要是考虑以下几个方面：可用性、一致性、持久性、可恢复性、伸缩性以及性能。例如，使用点对点的无主设计的nosql数据库在一个节点故障后必须启动数据修复和重新平衡的过程，这些过程的代价很大。重新平衡的进程会严重影响系统的吞吐量和延迟，客户端等待恢复的时候会造成连接堵塞，进而导致应用出现故障。为了避免这种情况，eBay在无主数据库的上层增加了一个应用层面的分片，这个方法最初是为oracle设计的。DBA使用这种方式可以把一个大的集群分解成一系列的子集群，把重建的负荷放在个别节点上，只影响个别查询操作。正是为了应对不同类型的数据库行为，eBay才建立的弹性设计模式。

Qu先生为我们展示了下图的MongoDB弹性设计模式

在这种设计模式下，MongoDB复制集的7个节点分布在eBay在美国的三个不同的数据中心。这种模式可以在主节点遇到故障时，数据库集群可以保持可用性。可以为MongoDB的复制集成员分配优先级，这个优先级可以决定主节点遇到故障后哪个次节点可以被推举为新的主节点。例如，可以设定在主节点故障后，位于DC1的节点可以优先被选举为主节点。只有DC1中多有的节点都出现故障，DC2中的成员才可以被选举为主节点，当然新的节点选举的依据是，从原来节点中同步到最新的数据的节点才是主节点。这种模式的一个延伸做法是使用MongoDB的“大多数写入关注”来保证跨数据中心的写入持久性。

MongoDB的标准设计模式是eBay的“高密集、高可用读取模式”的基础，此模式用于支撑eBay的产品目录模块。为了应对产品目录模块的压力，需要把MongoDB的复制集成员扩展到50个，为读取扩展性以及弹性提供了分布式数据架构。

eBay开发了“高性能读写模式”以支撑高密度的写入压力，这种模式是把MongoDB集群的分片服务器分布在美国不同数据中心。

同样，开发人员可以对这种模式具体的读写关注进行设置，调整系统持久性以及弹性以满足不同应用的需求。

Qu先生指出，随着MongoDB的功能的增强，MongoDB可以用来满足更多的应用需求：

l MongoDB3.4中引入的zone sharding功能可以使eBay支撑那些对分布式以及持续写入可用性要求较高的应用。

l 即将在MongoDB3.6中发布的可重写操作，可以减少应用端的异常处理代码

如果想深入了解eBay的设计模式，可以参考Feng Qu在MongoDB大会上的分享。