如何利用MongoDB实现高性能，高可用的双活应用架构？

投资界有一句至理名言——“不要把鸡蛋放在同一个篮子里”。说的是投资需要分解风险，以免孤注一掷失败之后造成巨大的损失。

随着企业服务窗口的不断增加，业务中断对很多企业意味着毁灭性的灾难，因此，跨多个数据中心的应用部署成为了当下热门的话题之一。

如今，在跨多个数据中心的应用部署佳实践中，数据库通常负责处理多个地理区域的读取和写入，对数据变更的复制，并提供尽可能高的可用性、一致性和持久性。

但是，并非所有的技术在选择上都是平等的。例如，一种数据库技术可以提供更高的可用性保证，却同时只能提供比另一种技术更低的数据一致性和持久性保证。

本文先分析了在现代多数据中心中应用对于数据库架构的需求。随后探讨了数据库架构的种类及优缺点，后专门研究 MongoDB 如何适用于这些类别，并终实现双活的应用架构。

双活的需求

当组织考虑在多个跨数据中心（或区域云）部署应用时，他们通常会希望使用“双活”的架构，即所有数据中心的应用服务器同时处理所有的请求。

图 1：“双活”应用架构

如图 1 所示，该架构可以实现如下目标：

• 通过提供本地处理（延迟会比较低），为来自全球的请求提供服务。
• 即使出现整个区域性的宕机，也能始终保持高可用性。
• 通过对多个数据中心里服务器资源的并行使用，来处理各类应用请求，并达到佳的平台资源利用率。

“双活”架构的替代方案是由一个主数据中心（区域）和多个灾备（DR）区域（如图 2 所示）所组成的主-DR（也称为主-被）架构。

图 2：主-DR 架构

在正常运行条件下，主数据中心处理请求，而 DR 站点处于空闲状态。如果主数据中心发生故障，DR 站点立即开始处理请求（同时变为活动状态）。

一般情况下，数据会从主数据中心复制到 DR 站点，以便在主数据中心出现故障时，能够迅速实施接管。

如今，对于双活架构的定义尚未得到业界的普遍认同，上述主-DR 的应用架构有时也被算作“双活”。

区别在于从主站到 DR 站点的故障转移速度是否够快（通常为几秒），并且是否能够自动化（无需人为干预）。在这样的解释中，双活体系架构意味着应用停机时间接近于零。

有一种常见的误解，认为双活的应用架构需要有多主数据库。这样理解是错误的，因为它曲解了多个主数据库对于数据一致性和持久性的把握。

一致性确保了能读取到先前写入的结果，而数据持久性则确保了提交的写入数据能够被保存，不会产生冲突写入；或是由于节点故障所产生的数据丢失。

双活应用的数据库需求

在设计双活的应用架构时，数据库层必须满足如下四个方面的架构需求（当然，也要具备标准数据库的功能，如具有：丰富的二级索引能力的查询语言，低延迟地访问数据，本地驱动程序，全面的操作工具等）：

• 性能，低延迟读取和写入操作。这意味着：能在本地数据中心应用的节点上，处理读取和写入操作。
• 数据持久性，通过向多个节点的复制写入来实现，以便在发生系统故障时，数据能保持不变。
• 一致性，确保能读取之前写入的结果，而且在不同地区和不同节点所读到的结果应该相同。
• 可用性，当某个节点、数据中心或网络连接中断时，数据库必须能继续运行。另外，从此类故障中恢复的时间应尽可能短，一般要求是几秒钟。

分布式数据库架构

针对双活的应用架构，一般有三种类型的数据库结构：

• 使用两步式提交的分布式事务。
• 多主数据库模式，有时也被称为“无主库模式”。
• 分割（分片）数据库具有多个主分片，每个主分片负责数据的某个片区。

下面让我们来看看每一种结构的优缺点。

两步式提交的分布式事务

分布式事务方法是在单次事务中更新所有包含某个记录的节点，而不是写完一个节点后，再（异步）复制到其他节点。

该事务保证了所有节点都会接收到更新，否则如果某个事务失败，则所有节点都恢复到之前的状态。

虽然两步式提交协议可以确保持久性和多节点的一致性，但是它牺牲了性能。

两步式提交协议要求在事务中所有参与的节点之间都要进行两步式的通信。即在操作的每个阶段，都要发送请求和确认，以确保每个节点同时完成了相同的写入。

当数据库节点分布在多个数据中心时，会将查询的延迟从毫秒级别延长到数秒级别。

而在大多数应用，尤其是那些客户端是用户设备（移动设备、Web 浏览器、客户端应用等）的应用中，这种响应级别是不可接受的。

多主数据库

多主数据库是一种分布式的数据库，它允许某条记录只在多个群集节点中一个之上被更新。而写操作通常会复制该记录到多个数据中心的多个节点上。

从表面上看，多主数据库应该是实现双活架构的理想方案。它使得每个应用服务器都能不受限地读取和写入本地数据的副本。但是，它在数据一致性上却有着严重的局限性。

由于同一记录的两个（或更多）副本可能在不同地点被不同的会话同时更新。这就会导致相同的记录会出现两个不同的版本，因此数据库（有时是应用本身）必须通过解决冲突来解决不一致的问题。

常用的冲突解决策略是：近的更新“获胜”，或是具有更多修改次数的记录“获胜”。因为如果使用其他更为复杂的解决策略，则性能上将受到显著的影响。

这也意味着，从进行写入到完成冲突解决机制的这个时间段内，不同的数据中心会读取到某个相同记录的不同值和冲突值。

分区（分片）数据库

分区数据库将数据库分成不同的分区，或称为分片。每个分片由一组服务器来实现，而每个服务器都包含一份分区数据的完整副本。这里关键在于每个分片都保持着对数据分区的独有控制权。

对于任何给定时间内的每个分片来说，由一台服务器充当主服务器，而其他服务器则充当其副本。数据的读取和写入被发布到主数据库上。

如果主服务器出于任何原因的（例如硬件或网络故障）失败，则某一台备用服务器会自动接任为主服务器的角色。

数据库中的每条记录都属于某个特定的分区，并由一个分片来进行管理，以确保它只会被主分片进行写入。分片内的记录映射到每个分片的一个主分片，以确保一致性。

由于集群内包含多个分片，因此会有多个主分片（多个主分区），因此这些主分片可以被分配到不同的数据中心，以确保都在每个数据中心的本地都能发生写入操作，如图 3 所示：

图 3：分区数据库

分片数据库可用于实现双活的应用架构，其方法是：至少部署与数据中心一样多的分片，并为分片分配主分片，以便每个数据中心至少有一个主分片，如图 4 所示：

图 4：具有分片数据库的双活架构

另外，通过配置分片能保证每个分片在各种数据中心里至少有一个副本（数据的副本）。

例如，图 4 中的图表描绘了跨三个数据中心的分布式数据库架构：

• 纽约（NYC）
• 伦敦（LON）
• 悉尼（SYD）

群集有三个分片，每个分片有三个副本：

• NYC 分片在纽约有一个主分片，在伦敦和悉尼有副本。
• LON 分片在伦敦有一个主分片，在纽约和悉尼有副本。
• SYD 分片在悉尼有一个主分片，在伦敦和纽约有副本。

通过这种方式，每个数据中心都有来自所有分片的副本，因此本地应用服务器可以读取整个数据集和一个分片的主分片，以便在其本地进行写入操作。

分片数据库能满足大多数使用场景的一致性和性能要求。由于读取和写入发生在本地服务器上，因此性能会非常好。

从主分片中读取时，由于每条记录只能分配给一个主分片，因此保证了一致性。

例如：我们在美国的新泽西州和俄勒冈州有两个数据中心，那么我们可以根据地理区域（东部和西部）来分割数据集，并将东海岸用户的流量路由到新泽西州的数据中心。

因为该数据中心包含的是主要用于东部的分片；并将西海岸用户的流量路由到俄勒冈州数据中心，因为该数据中心包含的是主要用于西部的分片。

我们可以看到分片的数据库为我们提供了多个主数据库的所有好处，而且避免了数据不一致所导致的复杂性。

应用服务器可以从本地主服务器上进行读取和写入，由于每个主服务器拥有各自的记录，因此不会出现任何的不一致。相反，多主数据库的解决方案则可能会造成数据丢失和读取的不一致。

数据库架构比较

图 5：数据库架构比较

图 5 提供了每一种数据库架构在满足双活应用需求时所存在的优缺点。在选择多主数据库和分区数据库时，其决定因素在于应用是否可以容忍可能出现的读取不一致和数据的丢失问题。

如果答案是肯定的，那么多主数据库可能会稍微容易部署些。而如果答案是否定的，那么分片数据库则是好的选择。

由于不一致性和数据丢失对于大多数应用来说都是不可接受的，因此分片数据库通常是佳的选择。

MongoDB 双活应用

MongoDB 是一个分片数据库架构的范例。在 MongoDB 中，主服务器和次服务器集的构造被称为副本集。副本集为每个分片提供了高可用性。

一种被称为区域分片（Zone Sharding）的机制被配置为：由每个分片去管理的数据集。如前面所提到的，ZoneSharding 可以实现地域分区。

白皮书《MongoDB多数据中心部署》：

• https://www.mongodb.com/collateral/mongodb-multi-data-center-deployments?utm_medium=dzone-synd&utm_source=dzone&utm_content=active-application&jmp=dzone-ref

Zone Sharding 相关文档：

• https://docs.mongodb.com/manual/tutorial/sharding-segmenting-data-by-location/的“分区（分片）数据库”部分描述了 MongoDB 具体实现和运作的细节。

其实许多组织，包括：Ebay、YouGov、Ogilvyand Maher 都正在使用 MongoDB 来实现双活的应用架构。

除了标准的分片数据库功能之外，MongoDB 还提供对写入耐久性和读取一致性的细粒度控制，并使其成为多数据中心部署的理想选择。对于写入，我们可以指定写入关注（write concern）来控制写入的持久性。

Writeconcern 使得应用在 MongoDB 确认写入之前，就能指定写入的副本数量，从而在一个或多个远程数据中心内的服务器上完成写入操作。籍此，它保证了在节点或数据中心发生故障时，数据库的变更不会被丢失。

另外，MongoDB 也补足了分片数据库的一个潜在缺点：写入可用性无法达到 100％。

由于每条记录只有一个主节点，因此如果该主节点发生故障，则会有一段时间不能对该分区进行写入。

MongoDB 通过多次尝试写入，大幅缩短了故障切换的时间。通过多次尝试的写入操作，MongoDB 能够自动应对由于网络故障等暂时性系统错误而导致的写入失败，因此也大幅简化了应用的代码量。

MongoDB 的另一个适合于多数据中心部署的显著特征是：MongoDB 自动故障切换的速度。

当节点或数据中心出现故障或发生网络中断时，MongoDB 能够在 2-5 秒内（当然也取决于对它的配置和网络本身的可靠性）进行故障切换。

发生故障后，剩余的副本集将根据配置去选择一个新的主切片和 MongoDB 驱动程序，从而自动识别出新的主切片。一旦故障切换完成，其恢复进程将自动履行后续的写入操作。

对于读取，MongoDB 提供了两种功能来指定所需的一致性级别。

首先，从次数据进行读取时，应用可以指定大时效值（maxStalenessSeconds）。

这可以确保次节点从主节点复制的滞后时间不能超过指定的时效值，从而次节点所返回的数据具有其时效性。

另外，读取也可以与读取关注（ReadConcern）相关联，来控制查询到的返回数据的一致性。

例如，ReadConcern 能通过一些返回值来告知 MongoDB，那些被复制到副本集中的多数节点上的数据。

这样可以确保查询只读取那些没有因为节点或数据中心故障而丢失的数据，并且还能为应用提供一段时间内数据的一致性视图。

MongoDB 3.6 还引入了“因果一致性（causal consistency）”的概念，以保证客户端会话中的每个读取操作，都始终只“关注”之前的写入操作是否已完成，而不管具体是哪个副本正在为请求提供服务。

通过在会话中对操作进行严格的因果排序，这种因果一致性可以确保每次读取都始终遵循逻辑上的一致，从而实现分布式系统的单调式读取（monotonic read）。而这正是各种多节点数据库所无法满足的。

因果一致性不但使开发人员，能够保留过去传统的单节点式关系型数据库，在实施过程中具备的数据严格一致性的优势；又能将时下流行架构充分利用到可扩展和具有高可用性的分布式数据平台之上。

感兴趣的可以自己来我的Java架构群，可以获取免费的学习资料，群号：855801563对Java技术，架构技术感兴趣的同学，欢迎加群，一起学习，相互讨论。