MongoDB高可用架构涉及常用功能整理

MongoDB高可用架构涉及常用功能整理

• [1. mongo架构和相关组件](#1. mongo架构和相关组件)
• • [1.1. Master-Slave主从模式](#1.1. Master-Slave主从模式)
  • [1.2. Replica Set 副本集模式](#1.2. Replica Set 副本集模式)
  • [1.3. Sharding 分片模式](#1.3. Sharding 分片模式)
• [2. Sharding 分片模式](#2. Sharding 分片模式)
• • [2.1. Hashed Sharding方式](#2.1. Hashed Sharding方式)
  • [2.2. Range Sharding方式](#2.2. Range Sharding方式)
• [3. 事务性](#3. 事务性)
• [4. 疑问和思考](#4. 疑问和思考)
• • [4.1. 怎么保证数据的高可靠？](#4.1. 怎么保证数据的高可靠？)
  • [4.2 怎么保证数据的强一致性？](#4.2 怎么保证数据的强一致性？)
• [5. 参考文档](#5. 参考文档)

MongoDB是一个开源的文档数据库，适用于构建各种类型的应用程序和用例。它是一种NoSQL数据库，意味着它不依赖关系模型，并且不使用SQL查询语言进行数据操作。

MongoDB的特点包括：

• 面向文档的数据模型：MongoDB存储的是以JSON风格的文档，可以包含各种类型的数据。文档的结构可以灵活地变化，便于处理复杂的数据。
• 高性能：MongoDB使用了一种称为BSON的二进制数据格式，以及一种称为聚集集合的存储引擎，以提供高性能的数据存储和查询操作。
• 可扩展性：MongoDB可以通过水平扩展集群来处理大规模的数据和高负载的请求。它支持自动分片和数据复制，以提供高可用性和可伸缩性。
• 强大的查询能力：MongoDB支持丰富的查询语法和索引功能，包括范围查询、全文搜索、地理位置查询等。
• 多种语言支持：MongoDB提供了多种编程语言的驱动程序，可以方便地与各种编程语言进行集成和开发。

本文主要探讨mongodb常见的高可用架构，以及mongo常用的功能，便于梳理知识点和技术细节。

关于常见分布式组件高可用设计原理的理解和思考

---

1. mongo架构和相关组件

mongo在目前有3种模式高可用架构，不同类型的高可用架构在高可用以及集群容量上表现有差异

• Master-Slave主从模式
• Replica Set 副本集模式
• Sharding 分片模式

1.1. Master-Slave主从模式

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

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

由两种角色构成：

• 主(Master)

  可读可写，当数据有修改的时候，会将 Oplog 同步到所有连接的Salve 上去。master节点完成数据写入后，就会返回可客户端，并异步同步到slave节点。 由于从节点无法保证事务性，因此常见的问题，就是主从数据不一致和主从延迟问题。

• 从(Slave)

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

主从架构有一个不可逾越的问题：数据不一致问题。根本原因在于只有 Master 节点可以写，Slave 节点只能同步 Master 数据并对外提供读服务，所以你会发现这个是一个异步的过程。

虽然最终数据会被 Slave 同步到，在数据完全一致之前，数据是不一致的，这个时候去 Slave 节点读就会读到旧的数据。所以，总结来说：读写分离的结构只适合特定场景，对于必须需要数据强一致的场景是不合适这种读写分离的。

当 Master 节点出现故障的时候，Slave节点不能自动切换为Master节点，需要通过人为 Check 和操作，手动把 Slave 节点指定为 Master 节点。对于Mongodb来说，并不推荐使用Master-Slave架构。

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

1.2. Replica Set 副本集模式

副本模式，是基于主从模式的升级版本，集群中的节点相互有心跳感知。当主节点宕机时，剩余节点重新选举一个节点升级为主节点，集群自动failover，提升集群高可用能力，从而避免需要人工干预才能恢复。

由3种角色组成

• Primary（ 主节点 ）

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

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

• Secondary（ 副本节点 ）

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

• Arbiter（ 仲裁者 ）

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

MongoDB的Replica Set模式中，选取主节点的过程是自动进行的，无需人工干预。当一个Replica Set启动时，初始选主过程即开始。

选主过程如下：

• 从Replica Set中选取一个成员作为初始主节点。
• 其他成员（副本集成员）将会投票选举。
• 在选举过程中，每个成员都会向其他成员发送心跳信号。
• 如果一个成员收到了其他成员的心跳信号，并且与其保持连接，则会响应一个选举请求。
• 选举请求得到半数以上成员的支持时，该成员将成为主节点。
• 其他成员将成为从节点，它们将与主节点进行数据同步。
• 主节点负责处理所有写操作，并将数据变更同步到从节点。从节点只能进行读操作，并且将按照主节点的顺序同步数据变更。

如果主节点故障或离线，副本集中的其他成员将会重新进行选举，选择一个新的主节点。在选主过程中，系统会自动处理主节点切换，并且在选主完成后，副本集中的所有成员将重新进行同步。

因此，MongoDB的Replica Set模式是自动选主的，无需人工干预，并且在主节点故障时也能自动进行切换。这确保了系统的高可用性和数据一致性。

1.3. Sharding 分片模式

按道理 Replica Set 模式已经非常好的解决了可用性问题，为什么还会往后演进呢？因为在当今大数据时代，有一个必须要考虑的问题：就是数据量。由于副本模式，所有节点保存的数据量都是一样的，并且是全量数据，因此单台节点的资源能力决定了整个集群能够承担的数据量，无法实现大量扩展。 为了解决该问题，mongo进一步演化出了分片模式，以提升集群的数据量。

分片模式，是常用的生产模式，也是本文的重点介绍对象。

Sharding 模式下按照层次划分可以分为 3 个大模块：

• 代理层：mongos
• 配置中心：副本集群（mongod）
• 数据层：Shard 集群

代理层：

代理层的组件也就是 mongos ，这是个无状态的组件，纯粹是路由功能。向上对接 Client ，收到 Client 写请求的时候，按照特定算法均衡散列到某一个 Shard 集群，然后数据就写到 Shard 集群了。收到读请求的时候，定位找到这个要读的对象在哪个 Shard 上，就把请求转发到这个 Shard 上，就能读到数据了。

数据层：

数据层是啥？就是存储数据的地方。你会惊奇的发现，其实数据层就是由一个个 Replica Set 集群组成。在前面我们说过，单个 Replica Set 是有极限的，怎么办？那就搞多个 Replica Set ，这样的一个 Replica Set 我们就叫做 Shard 。理论上，Replica Set 的集群的个数是可以无限增长的。

配置中心：

代理层是无状态的模块，数据层的每一个 Shard 是各自独立的，那总要有一个集群统配管理的地方，这个地方就是配置中心。里面记录的是什么呢？比如：有多少个 Shard，每个 Shard 集群又是由哪些节点组成的。每个 Shard 里大概存储了多少数据量（以便做均衡）。这些东西就是在配置中心的。配置中心存储的就是集群拓扑，管理的配置信息。这些信息也非常重要，所以也不能单点存储，怎么办？配置中心也是一个 Replica Set 集群，数据也是多副本的。

首先，要选一个字段（或者多个字段组合也可以）用来做 Key，这个 Key 可以是你任意指定的一个字段。我们现在就是要使用这个 Key 来，通过某种策略算出发往哪个 Shard 上。这个策略叫做：Sharding Strategy ，也就是分片策略。

我们把 Sharding Key 作为输入，按照特点的 Sharding Strategy 计算出一个值，值的集合形成了一个值域，我们按照固定步长去切分这个值域，每一个片叫做 Chunk ，每个 Chunk 出生的时候就和某个 Shard 绑定起来，这个绑定关系存储在配置中心里。

所以，我们看到 MongoDB 的用 Chunk 再做了一层抽象层，隔离了用户数据和 Shard 的位置，用户数据先按照分片策略算出落在哪个 Chunk 上，由于 Chunk 某一时刻只属于某一个 Shard，所以自然就知道用户数据存到哪个 Shard 了。

MongoDB使用了chunk作为数据的分片单位，每个chunk大小默认为64MB。chunk的作用如下：

• 数据划分：MongoDB将数据划分成多个chunk，并将这些chunk分散存储在不同的shard上。通过将数据划分成多个chunk，可以实现数据的分布式存储和并行处理，提高系统的吞吐量和扩展性。
• 数据迁移：当需要对数据进行重新分片或者在集群中增加或减少shard时，MongoDB会自动进行数据迁移。数据迁移时，MongoDB会将一个chunk从一个shard迁移到另一个shard上，以实现数据的平衡分布。
• 故障恢复：当一个shard失效时，MongoDB会将该shard上的chunk迁移到其他shard上。这样可以保证数据的可用性和容错性，即使部分shard失效，整个集群仍然可以正常工作。
• 查询优化：通过将数据划分成多个chunk，MongoDB可以根据查询条件只在包含相关数据的chunk上进行查询，从而减少查询的范围，提高查询的效率。

这种数据模式，在很多分布式存储产品中都是用，通过设计一个逻辑层的数据存储逻辑单元，将数据切割成固定大小，进行进行数据存储。从而将用户数据和实际的物理存储隔离开，便于后续的数据备份、迁移和热点转移。

2. Sharding 分片模式

mongo分片模式的数据分片策略主要分为

• Hashed Sharding 的方式
• Range Sharding 的方式

2.1. Hashed Sharding方式

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

这种计算值域的方式有什么优缺点呢？

好处是：

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

坏处是：

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

2.2. Range Sharding方式

Range 的方式本质上是直接用 Key 本身来做值，形成的 Key Space ，同类型的key保存在相同的chunk，将相似性高的数据存放在一起，能够得到更好的排序性能

如上图例子，Sharding Key 选为 name 这个字段，对于 "test_0″，"test_1″，"test_2" 这样的 key 排序就是挨着的，所以就全都分配在一个 Chunk 里。

这 3 条 Docuement 大概率是在一个 Chunk 上，因为我们就是按照 Name 来排序的。这种方式有什么优缺点？

好处是：

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

坏处是：

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

3. 事务性

参考官方文档 MongoDB-CN-Manual

4. 疑问和思考

4.1. 怎么保证数据的高可靠？

客户端配置写多数成功才算成功。没错，这个权限交由由客户端配置。如果没有配置写多数成功，那么很可能写一份数据成功就成功了，这个时候如果发生故障，或者切主，那么数据可能丢失或者被主节点 rollback ，也等同用户数据丢失。

mongodb 有完善的 rollback 及写入策略(WriteConcern)机制，但是也要使用得当。怎么保证高可靠？一定要写多数成功才算成功。

4.2 怎么保证数据的强一致性？

客户端要配置两个东西：

• 写多数成功，才算成功；
• 读使用 strong 模式，也就是只从主节点读；

只有这两个配置一起上，才能保证用户数据的绝对安全，并且对外提供数据的强一致性。

5. 参考文档

• 暂无