澳门新葡亰信誉平台游戏如何利用MongoDB实现高性能,高可用的双活应用架构?

by admin on 2020年3月15日

刚刚 GitHub 通过官方博客发布了 21
日“挂掉”的事件分析。

(草稿)

澳门新葡亰信誉平台游戏 1

澳门新葡亰信誉平台游戏 2

目录

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

GitHub 指出此次事件发生的原因是在 10 月 21 日 22:52 UTC
进行日常维护——更换发生故障的 100G
光纤设备时导致美国东海岸网络中心与美国东海岸数据中心之间的连接断开。

第五章 MongoDB部署模式

下图显示MongoDB中的数据中心awareness如何为地域和全球部署提供高可用性和可扩展性。

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

澳门新葡亰信誉平台游戏 3

高可用:单数据中心

在数据中心内,复制集可以分布在机架上,以便任一机架都不会包含一个给定分片的多个复制成员。

在这配置中可以容忍服务器和机架故障,复制集成员的数量决定系统可持续承受故障的规模,而不影响可用性。这种部署不会对数据中心本身的故障容错。

澳门新葡亰信誉平台游戏 4

图3:单数据中心-服务器和机架容错

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

更具体地,GitHub 分析,虽然两地的连接在 43
秒内恢复,但这次短暂的中断引发了一系列事件,这才导致了长达 24 小时 11
分钟的服务降级。

高可用:主/备 数据中心

在典型的灾难恢复中,复制集成员分布在两个数据中心的机架上。活动的数据中心(西部数据中心)包括一个偶数的复制集成员其中包含主成员。

澳门新葡亰信誉平台游戏 5

图4:主/备 数据中心 – 数据中心容错

东部的备用或灾难恢复数据中心配有副复制集成员,配置较低的选举优先级(建议使用0.5)。这样可以确保只有West数据中心的节点才是主(Primary),除非一个数据中心完全中断它们才完全不可用。在活动/备份配置中,用户能避免任一数据中心丢失,而应用程序可能使用大部分write
concern保持在任何服务器故障时写保护。

在西部数据中心发生故障时,运营团队的重点是把东部投入生产环境,同时要防止西部数据恢复时,一种“裂脑”(split
brain)的可能性。去做这个,管理员必须确保西部至少有一个MongoDB节点停留下来,通过一定的措施,如移除电源或确认西部的永久性物理损失。下一步一个在东部节点上的“强制”重配置复制集移除西部两个成员的投票。东部节点大部分立即选举自己为主(Primary)并恢复生产能力。如果西部在任何时间停止服务,额外的复制集成员应该添加至东部为MongoDB部署恢复冗余。在更可能出现的西部恢复事件中,应采取以下步骤:

一旦连接恢复,在西部恢复的复制集成员自动同步当前东部的主复制集。东部剩下有投票权的成员以单独表决的形式选出西部较高优先级的节点为主(Primary)。

重启西部剩余的复制集。它会自动重新同步其余的复制集并承担次级角色。

恢复对西部MongoDB节点的选举投票权,完成恢复至初始状态。当加上MongoDB的持续备份和指定时间恢复工具,主/备设计模式在此示例中将通过灾难恢复和低PRO(目标点恢复)提供业务连续性。然而,它是分布式架构,MongoDB提供更灵活的配置支持主/主数据中心配置。

请注意此部署适用于单复制集或为一个未使用集群负载均衡的分片集群。负载均衡器在用于围绕集群自动重发数据的多数据中心环境中,建议在一个主/主数据中心配置中部署MongoDB。

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

为了大规模提高性能,GitHub
的应用程序将直接写入每个群集的相关主数据库,但在绝大多数情况下将读取请求委派给副本服务器的子集。GitHub
使用 Orchestrator 来管理 MySQL 集群拓扑并处理自动故障转移,Orchestrator
在此过程中考虑了许多变量,并在 Raft 共识机制之上达成共识。Orchestrator
可以实现应用程序无法支持的拓扑,因此必须注意将 Orchestrator
的配置与应用程序级别的期望保持一致。

高可用:主/主数据中心

两个数据中心,在这个例子中”西部“和”东部“配置相等数量的复制集成员,一个第三方数据中心(”中心“)包含一个附加的复制集成员。这个配置需要确保如果数据中心之中一个故障,大多数的复制集成员能构成一个法定人数(所以如果西部数据中心故障,剩下的两个数据中心能对集群状态达成一致并切换到东部数据中心)。

澳门新葡亰信誉平台游戏 6

图5:主/主 数据中心 – 服务器、机架与数据中心加网络中断容错

双活的需求

澳门新葡亰信誉平台游戏 7

高可扩展性:全球数据分布

为减少地理环境因素的影响,MongoDB可以将数据复制到本地站点。读操作可以通过 nearest 发布一个优先读取。根据一个ping距离,确保从最接近用户的数据中心提供数据。

这些读操作与主(Primary)保证最终一致,但通常不超过几毫秒在主(Primary)之后,加网络延迟。写操作发布给主(Primary)。

这种部署类型的典型用户案例是将数据和内容分发到地域远程受众。数据集被写入主(Primary)服务器,然后在这些数据中心被本地用户低延迟访问时将它们广播到世界各地的数据中的复制集成员。

澳门新葡亰信誉平台游戏 8

图6:全球数据分布 – 消除地域读取延迟

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

然而 21 日,在网络分区过程中,Orchestrator 在主数据中心根据 Raft
的共识机制,执行了取消领导的选举(leadership
deselection)。美国西海岸数据中心和美国东海岸公有云 Orchestrator
节点获得合规票数,并开始对群集进行故障转移,将写入指向美国西海岸数据中心。Orchestrator
继续组织美国西海岸数据库集群拓扑,当连接恢复时,应用层立即开始将写入流量引导到西海岸站点的新当选主节点上。

澳门新葡亰信誉平台游戏 9

美国东海岸数据中心的数据库服务器包含一小段时间的写入数据,它们尚未复制到美国西海岸的设施。由于两个数据中心中的数据库集群都包含了其它数据中心中不存在的写入数据,因此无法安全地将主数据库故障转移到美国东海岸数据中心。

高可扩展性:本地读操作/全局写操作

使用区分片,管理员能将数据库的特定分区引导到特定的地理区域。每个区域都是一样的,单集群能被全球查询到,但数据位于独立和本地访问需求的正确位置。通过根据用户位置将数据关联到分片,管理员能够保持低延迟访问。

为进一步说明,一个应用程序可以用友北美,欧洲和中国的用户。应用程序所有者可以将每个分片分配给改分片服务器的物理位置(北美,欧洲或中国)的区域,然后根据其区域字段将所有文档映射到正确的区(Zone)。任何数量的分片都可以和每个区(Zone)关联并且每个区都可以独立其他的进行扩展。例如,比起北美,中国的用户增长速度更快。

在这部署中,每个MongoDB分片都被本地化至一个特定的数据中心。每个数据中心都有一个具有其分片的主复制集成员并还保留位于其他数据中心的次级复制集分片。应用程序能执行本地数据的读写操作以及从其他区域复制的数据的读操作。如果用户从一个数据中心移至另一个,则可以通过简单地更新分片区域轻松的迁移数据。

一个用户从他的本地位置漫游不同区域的移动应用代表这类部署的典型案例。使用适当的写入策略,对移动服务的任何更新能被路由回它通常的起始位置的数据中心(全局写入),同时通过使用nearest读取优先级(本地读取)将其路由到最近的物理数据中心。

另一个案例是内容管理和交付。例如,McAfee全球Threat集成平台将内容更新写入最每个用户的数据中心,然后使用nearest读取优先级对该数据进行低延迟访问。

澳门新葡亰信誉平台游戏 10

图7:本地读/全局写 – 启用移动应用

通过查看我们关于使用MongoDB区域创建地理位置分布式集群的教程了解更多信息:(

图 1:“双活”应用架构

澳门新葡亰信誉平台游戏 11

分布式本地写入为Always-On 写入仅工作负载

MongoDB
区域通过为写入仅工作负载的持续可用性提供了解决方案,例如在IoT应用程序中摄入传感器数据。区域可用于本地化写入在一个分布式集群中创建特定地配置,确保即使在数据中心故障期间总是有可用的接受写入的节点。如图8所示,分布式本地写入的拓扑将维护每个数据中心的两个分片的节点。如果数据中心不可用,应用端逻辑能自动修改分片密匙去重定向写入到备用数据中心。

澳门新葡亰信誉平台游戏 12

图8:维护MongoDB zones的持续可用性和本地写操作

通过查看我们关于使用MongoDB区域配置本地化写操作的教程了解更多信息。

下一章 管理多数据中心部署

本文译者:吴锦晟 R&D Director@MFG

原文链接:

版权归译者所有,转载请注明出处

如图 1 所示,该架构可以实现如下目标:

GitHub
工程师发现问题后进行了一系列抢救措施,“最终没有用户数据丢失,但是,几秒钟的数据库写入的手动协调仍在进行中。”

通过提供本地处理,为来自全球的请求提供服务。

而之所以服务降级时间长达 24 小时 11 分,是因为在此次事件中,GitHub
的策略是优先考虑用户数据完整性,而不是站点可用性和恢复时间。

即使出现整个区域性的宕机,也能始终保持高可用性。

GitHub
对所有受影响的用户表示歉意,并表示“我们已经吸取了教训,并且采取了一系列措施,我们希望更好地确保不再发生类似情况。”

通过对多个数据中心里服务器资源的并行使用,来处理各类应用请求,并达到最佳的平台资源利用率。

同时 GitHub 也表示接下来将进一步解决由此导致的数据不一致问题。

“双活”架构的替代方案是由一个主数据中心和多个灾备区域所组成的主-DR架构。

详细分析与事件时间线请查阅 GitHub
公告。

澳门新葡亰信誉平台游戏 13

(文/开源中国)    

图 2:主-DR 架构

在正常运行条件下,主数据中心处理请求,而 DR
站点处于空闲状态。如果主数据中心发生故障,DR 站点立即开始处理请求。

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

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

区别在于从主站到 DR
站点的故障转移速度是否够快,并且是否能够自动化。在这样的解释中,双活体系架构意味着应用停机时间接近于零。

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

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

双活应用的数据库需求

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

性能,低延迟读取和写入操作。这意味着:能在本地数据中心应用的节点上,处理读取和写入操作。

数据持久性,通过向多个节点的复制写入来实现,以便在发生系统故障时,数据能保持不变。

一致性,确保能读取之前写入的结果,而且在不同地区和不同节点所读到的结果应该相同。

可用性,当某个节点、数据中心或网络连接中断时,数据库必须能继续运行。另外,从此类故障中恢复的时间应尽可能短,一般要求是几秒钟。

分布式数据库架构

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

使用两步式提交的分布式事务。

多主数据库模式,有时也被称为“无主库模式”。

分割数据库具有多个主分片,每个主分片负责数据的某个唯一片区。

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

两步式提交的分布式事务

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

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

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

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

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

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

多主数据库

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

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

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

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

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

分区数据库

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

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

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

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

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

澳门新葡亰信誉平台游戏 14

图 3:分区数据库

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

澳门新葡亰信誉平台游戏 15

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

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

纽约

伦敦

悉尼

群集有三个分片,每个分片有三个副本:

NYC 分片在纽约有一个主分片,在伦敦和悉尼有副本。

LON 分片在伦敦有一个主分片,在纽约和悉尼有副本。

SYD 分片在悉尼有一个主分片,在伦敦和纽约有副本。

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

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

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

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

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

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

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

数据库架构比较

澳门新葡亰信誉平台游戏 16

图 5:数据库架构比较

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

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

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

MongoDB 双活应用

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

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

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

Zone Sharding
相关文档:
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)。而这正是各种多节点数据库所无法满足的。

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图