MongoDB 的集群架构与设计

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: MongoDB 的集群架构与设计

一、前言

MongoDB 有三种集群架构模式,分别为主从复制(Master-Slaver)、副本集(Replica Set)和分片(Sharding)模式。

  • Master-Slaver 是一种主从复制的模式,目前已经不推荐使用。
  • Replica Set 模式取代了 Master-Slaver 模式,是一种互为主从的关系。Replica Set 将数据复制多份保存,不同服务器保存同一份数据,在出现故障时自动切换,实现故障转移,在实际生产中非常实用。
  • Sharding 模式适合处理大量数据,它将数据分开存储,不同服务器保存不同的数据,所有服务器数据的总和即为整个数据集。

二、主从复制模式

MongoDB 提供的第一种冗余策略就是 Master-Slave 策略,这个也是分布式系统最开始的冗余策略,这种是一种热备策略。

Master-Slave 架构一般用于备份或者做读写分离,一般是一主一从设计和一主多从设计。

Master-Slave 由主从角色构成:

Master ( 主 )

可读可写,当数据有修改的时候,会将 Oplog 同步到所有连接的 Salve 上去。

Slave ( 从 )

只读,所有的 Slave 从 Master 同步数据,从节点与从节点之间不感知。

如图:

2.1 主从复制对读写分离的思考

主从复制老生常谈的问题:数据不一致的问题。

根本原因在于只有 Master 节点可以写,Slave 节点只能同步 Master 数据并对外提供读服务,当你查询 Slave 节点的数据时,由于网络延迟等其它因素导致 Slave 节点还没有完全同步 Master 节点的数据,这就会导致主从不一致,跟 MySQL 的主从复制如出一辙,只不过 MySQL 时 binlog 同步,而 MongoDB 是 oplog 同步。

所以,总结来说:读写分离的架构只适合特定场景,对于必须需要数据强一致的场景是不合适这种读写分离的。

2.2 主从复制对容灾的思考

当 Master 节点出现故障的时候,由于 Slave 节点有备份数据,可以通过人为 Check 和操作,手动把 Slave 节点指定为 Master 节点,这样又能对外提供服务了。

  • Master-Slave 只区分两种角色:Master 节点,Slave 节点;
  • Master-Slave 的角色是静态配置的,不能自动切换角色,必须人为指定;
  • 用户只能写 Master 节点,Slave 节点只能从 Master 拉数据;
  • 还有一个关键点:Slave 节点只和 Master 通信,Slave 之间相互不感知,这种好处对于 Master 来说优点是非常轻量,缺点是:系统明显存在单点,那么多 Slave 只能从 Master 拉数据,而无法提供自己的判断;

MongoDB 3.6 起已不推荐使用主从模式,自 MongoDB 3.2 起,分片群集组件已弃用主从复制。因为 Master-Slave 其中 Master 宕机后不能自动恢复,只能靠人为操作,可靠性也差,操作不当就存在丢数据的风险。

三、副本集模式

3.1 副本集模式角色

副本集(Replica Set)是 mongod 的实例集合,包含三类节点角色:

Primary( 主节点 )

只有 Primary 是可读可写的,Primary 接收所有的写请求,然后把数据同步到所有 Secondary 。一个 Replica Set 只有一个 Primary 节点,当 Primary 挂掉后,其他 Secondary 或者 Arbiter 节点会重新选举出来一个 Primary 节点,这样就又可以提供服务了。

读请求默认是发到 Primary 节点处理,如果需要故意转发到 Secondary 需要客户端修改一下配置(注意:是客户端配置,决策权在客户端)。

那有人又会想了,这里也存在 Primary 和 Secondary 节点角色的分类,岂不是也存在单点问题?

这里和 Master-Slave 模式的最大区别在于,Primary 角色是通过整个集群共同选举出来的,人人都可能成为 Primary ,人人最开始只是  Secondary ,而这个选举过程完全自动,不需要人为参与。

Secondary( 副本节点 )

数据副本节点,当主节点挂掉的时候,参与选主。

思考一个问题:Secondary 和 Master-Slave 模式的 Slave 角色有什么区别?

最根本的一个不同在于:Secondary 相互有心跳,Secondary 可以作为数据源,Replica 可以是一种链式的复制模式。

Arbiter( 仲裁者 )

不存数据,不会被选为主,只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份,又能提供高可用的能力。

如下图:

3.2 为什么要使用副本集?

3.2.1 高可用

  • 防止设备(服务器、网络)故障
  • 提供自动 failover 功能
  • 技术来保证高可用

3.2.2 灾难恢复

  • 当发生故障时,可以从其他节点恢复,用于备份。

3.2.3 功能隔离

  • 我们可以在备节点上执行读操作,减少主节点的压力
  • 比如:用于分析、报表,数据挖掘,系统任务等。

3.3 副本集集群架构原理

一个副本集中Primary节点上能够完成读写操作,Secondary节点仅能用于读操作。Primary节点需要记录所有改变数据库状态的操作,这些记录保存在 oplog 中,这个文件存储在 local 数据库,各个Secondary 节点通过此 oplog 来复制数据并应用于本地,保持本地的数据与主节点的一致。oplog 具有幂等性,即无论执行几次其结果一致,这个比 mysql 的二进制日志更好用。

oplog的组成结构

{
    "ts" : Timestamp(1446011584, 2),
    "h" : NumberLong("1687359108795812092"),
    "v" : 2,
    "op" : "i",
    "ns" : "test.nosql",
    "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "10"}
}
ts:操作时间,当前timestamp + 计数器,计数器每秒都被重置
h:操作的全局唯一标识
v:oplog版本信息
op:操作类型
    i:插入操作
    u:更新操作
    d:删除操作 
    c:执行命令(如createDatabase,dropDatabase)
n:空操作,特殊用途
ns:操作针对的集合
o:操作内容 
o2:更新查询条件,仅update操作包含该字段

副本集数据同步分为初始化同步keep复制同步。初始化同步指全量从主节点同步数据,如果Primary 节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后,节点之间的实时同步一般是增量同步。

初始化同步有以下两种情况会触发:

  • Secondary 第一次加入。
  • Secondary 落后的数据量超过了 oplog 的大小,这样也会被全量复制。

MongoDBPrimary节点选举基于心跳触发。一个复制集N个节点中的任意两个节点维持心跳,每个节点维护其他N-1个节点的状态。

心跳检测:

整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每2秒就会发送一次pings包,如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表,表明当前每个节点是什么角色、日志时间戳等关键信息。如果主节点发现自己无法与大部分节点通讯则把自己降级为secondary只读节点。

主节点选举触发的时机:

第一次初始化一个副本集

  • Secondary节点权重比Primary节点高时,发起替换选举
  • Secondary节点发现集群中没有Primary时,发起选举
  • Primary节点不能访问到大部分(Majority)成员时主动降级

当触发选举时,Secondary节点尝试将自身选举为Primary。主节点选举是一个二阶段过程+多数派协议。

第一阶段:

检测自身是否有被选举的资格,如果符合资格会向其它节点发起本节点是否有选举资格的 FreshnessCheck,进行同僚仲裁。

第二阶段:

发起者向集群中存活节点发送Elect(选举)请求,仲裁者收到请求的节点会执行一系列合法性检查,如果检查通过,则仲裁者(一个复制集中最多50个节点,其中只有7个具有投票权)给发起者投一票。

pv0通过30秒选举锁防止一次选举中两次投票。

pv1使用了terms(一个单调递增的选举计数器)来防止在一次选举中投两次票的情况。

多数派协议:

发起者如果获得超过半数的投票,则选举通过,自身成为Primary节点。获得低于半数选票的原因,除了常见的网络问题外,相同优先级的节点同时通过第一阶段的同僚仲裁并进入第二阶段也是一个原因。因此,当选票不足时,会sleep[0,1]秒内的随机时间,之后再次尝试选举。

四、分片模式

4.1 什么是分片

分片 (sharding) 是MongoDB用来将大型集合水平分割到不同服务器(或者副本集)上所采用的方法。不需要功能强大的大型计算机就可以存储更多的数据,处理更大的负载。

4.2 为什么要分片

  • 存储容量需求超出单机磁盘容量。
  • 活跃的数据集超出单机内存容量,导致很多请求都要从磁盘读取数据,影响性能。
  • IOPS超出单个MongoDB节点的服务能力,随着数据的增长,单机实例的瓶颈会越来越明显。
  • 副本集具有节点数量限制。

垂直扩展:增加更多的CPU和存储资源来扩展容量。

水平扩展:将数据集分布在多个服务器上,水平扩展即分片。

4.3 分片的工作原理

整体架构图:

详细架构图:

分片集群由以下3个服务组成:

  • Router Server: 数据库集群的请求入口,所有请求都通过Router(mongos)进行协调,不需要在应用程序添加一个路由选择器,Router(mongos)就是一个请求分发中心它负责把应用程序的请求转发到对应的 Shard服务器上。
  • Shards Server: 每个shard由一个或多个mongod进程组成,用于存储数据。
  • Config Server: 配置服务器。存储所有数据库元信息(路由、分片)的配置。

4.3.1 片键(shard key)

为了在数据集合中分配文档,MongoDB使用分片主键分割集合。

4.3.2 区块(chunk)

在一个shard server内部,MongoDB还是会把数据分为chunks,每个chunk代表这个shard server内部一部分数据。MongoDB分割分片数据到区块,每一个区块包含基于分片主键的左闭右开的区间范围。

4.3.3 分片策略

4.3.3.1 hash分片(Hashed Sharding)

把 Key 作为输入,输入到一个 Hash 函数中,计算出一个整数值,值的集合形成了一个值域,我们按照固定步长去切分这个值域,每一个片叫做 Chunk ,这里的 Chunk 则就是整数的一段范围而已。

优点:

  • 计算速度快
  • 均衡性好,纯随机

缺点:

  • 正因为纯随机,排序列举的性能极差,比如你如果按照 name 这个字段去列举数据,你会发现几乎所有的 Shard 都要参与进来;

4.3.3.2 范围分片(Ranged Sharding)

优点:

  • 对排序列举场景非常友好,因为数据本来就是按照顺序依次放在 Shard 上的,排序列举的时候,顺序读即可,非常快速;

缺点:

  • 容易导致热点,举个例子,如果 Sharding Key 都有相同前缀,那么大概率会分配到同一个 Shard 上,就盯着这个 Shard 写,其他 Shard 空闲的很,却帮不上忙;

4.3.3.3 zone 分片(Zones in Sharded Clusters)

简单来说 Zone 实际上像是范围分片的另一个版本,你为一定范围内的片键制定一个 Zone,然后再将一些分片加入到这个  Zone 中,于是这一范围内的数据最终就将存储在这个 Zone 中的分片上。

五、总结

本文介绍了 3 种 MongoDB 的高可用架构,Master-Slave 模式,Replica Set 模式,Sharding 模式,这也是常见的架构演进的过程,是不是有点恍惚,Redis 也是类似这种架构的演进。

  • MongoDB Master-Slave 已经不推荐,甚至新版已经不支持这种冗余模式;
  • Replica Set 通过数据多副本,组件冗余提高了可靠性,并且通过分布式自动选主算法,减少了停服时间窗,提高了可用性;
  • Sharding 模式通过横向扩容的方式,为用户提供了近乎无限的空间;
  • MongoDB 客户端掌握了很大的配置权限,通过指定写多数策略和 strong 模式(只从主节点读数据)能保证数据的高可靠和强一致性;
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
2月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
3月前
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
3月前
|
存储 NoSQL Redis
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
|
4月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
279 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
4月前
|
存储 SQL 并行计算
【赵渝强老师】达梦数据库MPP集群的架构
达梦数据库提供大规模并行处理(MPP)架构,以低成本实现高性能并行计算,满足海量数据存储和复杂查询需求。DM MPP采用完全对等无共享体系,消除主节点瓶颈,通过多节点并行执行提升性能。其执行流程包括主EP生成计划、分发任务、各EP并行处理及结果汇总返回。为确保高可用性,建议结合数据守护部署。
107 0
|
5月前
|
存储 NoSQL 安全
客户说|知乎核心业务MongoDB集群的平滑上云迁移实践
客户说|知乎核心业务MongoDB集群的平滑上云迁移实践
168 0
|
7月前
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
231 0
|
3月前
|
NoSQL MongoDB 数据库
数据库数据恢复——MongoDB数据库服务无法启动的数据恢复案例
MongoDB数据库数据恢复环境: 一台Windows Server操作系统虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 管理员在未关闭MongoDB服务的情况下拷贝数据库文件。将MongoDB数据库文件拷贝到其他分区后,对MongoDB数据库所在原分区进行了格式化操作。格式化完成后将数据库文件拷回原分区,并重新启动MongoDB服务。发现服务无法启动并报错。
|
4月前
|
存储 NoSQL MongoDB
微服务——MongoDB常用命令1——数据库操作
本节介绍了 MongoDB 中数据库的选择、创建与删除操作。使用 `use 数据库名称` 可选择或创建数据库,若数据库不存在则自动创建。通过 `show dbs` 或 `show databases` 查看所有可访问的数据库,用 `db` 命令查看当前数据库。注意,集合仅在插入数据后才会真正创建。数据库命名需遵循 UTF-8 格式,避免特殊字符,长度不超过 64 字节,且部分名称如 `admin`、`local` 和 `config` 为系统保留。删除数据库可通过 `db.dropDatabase()` 实现,主要用于移除已持久化的数据库。
200 0

热门文章

最新文章

推荐镜像

更多