MongoDB~高可用集群介绍：复制集群（副本集）、分片集群

背景

MongoDB 的集群主要包括副本集（Replica Set）和分片集群（Sharded Cluster）两种类型。

1. 副本集

组成：通常由一个主节点（Primary）和多个从节点（Secondary）构成。

功能：

主节点负责处理读写操作。
从节点从主节点复制数据以保持同步，和读操作。
当主节点故障时，会自动进行选举，从从节点中选出新的主节点，保障系统的高可用性。

优点：

提供数据冗余，防止数据丢失。
实现读写分离，减轻主节点的读压力。

1. 分片集群

组成：

包含配置服务器（Config Server）、路由服务器（mongos）和多个分片（Shard）。
每个分片可以是一个副本集。

功能：

配置服务器存储集群的元数据，如分片的分布和配置信息。
路由服务器接收客户端的请求，并根据数据分布将请求路由到正确的分片。
分片负责存储实际的数据。

优点：

能够处理大规模的数据和高并发的读写请求。
通过将数据分布到多个分片上，实现水平扩展。
在实际应用中，根据数据量、读写负载、可用性要求等因素选择适合的集群类型，并进行合理的配置和优化，以确保 MongoDB 集群的性能和稳定性。

复制集群

MongoDB 的复制集群又称为副本集群，是一组维护相同数据集合的 mongod 进程。客户端连接到整个 Mongodb 复制集群，主节点机负责整个复制集群的写，从节点可以进行读操作，但默认还是主节点负责整个复制集群的读。主节点发生故障时，自动从从节点中选举出一个新的主节点，确保集群的正常使用，这对于客户端来说是无感知的。

通常来说，一个复制集群包含 1 个主节点（Primary），多个从节点（Secondary）以及1个或 N 个仲裁节点（Arbiter，建议是奇数个）。

主节点：整个集群的写操作入口，接收所有的写操作，并将集合所有的变化记录到操作日志中，即 oplog。主节点挂掉之后会自动选出新的主节点。
从节点：从主节点同步数据，在主节点挂掉之后选举新节点。不过，从节点可以配置成 0 优先级，阻止它在选举中成为主节点。
仲裁节点：这个是为了节约资源或者多机房容灾用，只负责主节点选举时投票不存数据，保证能有节点获得多数赞成票。

主节点与备节点之间是通过 oplog（操作日志）来同步数据的。

oplog 是 local 库下的一个特殊的上限集合(Capped Collection) ，用来保存写操作所产生的增量日志，类似于 MySQL 中的 Binlog。上限集合类似于定长的循环队列，数据顺序追加到集合的尾部，当集合空间达到上限时，它会覆盖集合中最旧的文档。上限集合的数据将会被顺序写入到磁盘的固定空间内，所以，I/O 速度非常快。
在这里插入图片描述
当主节点上的一个写操作完成后，会向 oplog 集合写入一条对应的日志，而从节点则通过这个 oplog 不断拉取到新的日志，在本地进行回放以达到数据同步的目的。

副本集最多有一个主节点。如果当前主节点不可用，一个选举会抉择出新的主节点。MongoDB 的节点选举规则能够保证在 Primary 挂掉之后选取的新节点一定是集群中数据最全的一个。

选举过程

MongoDB 副本集的选举过程大致如下：

触发选举：当副本集的主节点不可用时，会触发选举过程。这可能是由于主节点故障、网络问题或其他原因导致的。

可以通过以下几种方式发现主节点不可用：

监控副本集状态：仲裁节点可以定期执行rs.status()命令来获取副本集的状态信息。该命令会返回一个包含副本集成员状态的文档。通过检查主节点的状态，可以确定它是否可用。
观察心跳机制：副本集成员之间会通过心跳机制相互通信。如果主节点在一段时间内没有响应心跳，其他成员可能会认为它不可用，并触发选举过程。

收集信息：副本集中的每个节点，以及仲裁节点，都会收集其他节点的信息，包括节点的状态、最后操作时间戳等。
投票：仲裁节点会对候选主节点进行投票。
选择候选节点：进度快的仲裁节点可以根据预设的规则和策略，以及投票信息决定哪个从节点应该成为新的主节点。这些规则可能包括节点的优先级、数据的新旧程度等。
选举出新的主节点：等待仲裁节点广播选择节点将成为新的主节点。
同步数据：新的主节点会与其他从节点进行数据同步，以确保数据的一致性。

选举过程中，副本集的节点会通过心跳机制相互通信，以检测其他节点的状态。如果某个节点在一段时间内没有响应心跳，就会被认为是不可用的。

副本集的选举过程是自动进行的，对应用程序来说是透明的。在选举过程中，副本集可能会暂时处于只读状态，直到新的主节点选举出来。

为了确保副本集的高可用性和可靠性，建议在副本集中配置多个节点，并合理设置节点的优先级和其他参数。此外，监控副本集的状态和及时处理故障也是很重要的。

为什么要用复制集群？

实现 failover：提供自动故障恢复的功能，主节点发生故障时，自动从从节点中选举出一个新的主节点，确保集群的正常使用，这对于客户端来说是无感知的。
实现读写分离：我们可以设置从节点上可以读取数据，主节点负责写入数据，这样的话就实现了读写分离，减轻了主节点读写压力过大的问题。MongoDB 4.0 之前版本如果主库压力不大,不建议读写分离，因为写会阻塞读，除非业务对响应时间不是非常关注以及读取历史数据接受一定时间延迟。

分片集群

分片集群是 MongoDB 的分布式版本，相较副本集，分片集群数据被均衡的分布在不同分片中，不仅大幅提升了整个集群的数据容量上限，也将读写的压力分散到不同分片，以解决副本集性能瓶颈的难题。

MongoDB 的分片集群由如下三个部分组成：
在这里插入图片描述

Config Servers：配置服务器，本质上是一个 MongoDB 的副本集，负责存储集群的各种元数据和配置，如分片地址、Chunks 等Mongos
路由服务，不存具体数据，从 Config 获取集群配置讲请求转发到特定的分片，并且整合分片结果返回给客户端
Shard：每个分片是整体数据的一部分子集，从 MongoDB3.6 版本开始，每个 Shard 必须部署为副本集（replica set）架构

为什么要用分片集群？

随着系统数据量以及吞吐量的增长，常见的解决办法有两种：垂直扩展和水平扩展。

垂直扩展通过增加单个服务器的能力来实现，比如磁盘空间、内存容量、CPU 数量等
水平扩展则通过将数据存储到多个服务器上来实现，根据需要添加额外的服务器以增加容量。

类似于 Redis Cluster，MongoDB 也可以通过分片实现水平扩展。

水平扩展这种方式更灵活，可以满足更大数据量的存储需求，支持更高吞吐量。并且，水平扩展所需的整体成本更低，仅仅需要相对较低配置的单机服务器即可，代价是增加了部署的基础设施和维护的复杂性。

也就是说当你遇到如下问题时，可以使用分片集群解决：存储容量受单机限制，即磁盘资源遭遇瓶颈。读写能力受单机限制，可能是 CPU、内存或者网卡等资源遭遇瓶颈，导致读写能力无法扩展。

分片键（Shard Key）

分片建是数据分区的前提，从而实现数据分发到不同服务器上，减轻服务器的负担。也就是说，分片键决定了集合内的文档如何在集群的多个分片间的分布状况。分片键就是文档里面的一个字段，但是这个字段不是普通的字段，有一定的要求：

它必须在所有文档中都出现。它必须是集合的一个索引，可以是单索引或复合索引的前缀索引，不能是多索引、文本索引或地理空间位置索引。
MongoDB 4.2 之前的版本，文档的分片键字段值不可变。
MongoDB 4.2 版本开始，除非分片键字段是不可变的 _id 字段，否则您可以更新文档的分片键值。
MongoDB 5.0 版本开始，实现了实时重新分片（live resharding），可以实现分片键的完全重新选择。
它的大小不能超过 512 字节。

如何选择分片键

选择合适的片键对 sharding 效率影响很大，主要基于如下四个因素:

取值基数 取值基数建议尽可能大，如果用小基数的片键，因为备选值有限，那么块的总数量就有限，随着数据增多，块的大小会越来越大，导致水平扩展时移动块会非常困难。例如：选择年龄做一个基数，范围最多只有 100 个，随着数据量增多，同一个值分布过多时，导致 chunck 的增长超出 chuncksize 的范围，引起 jumbo chunk，从而无法迁移，导致数据分布不均匀，性能瓶颈。
取值分布 取值分布建议尽量均匀，分布不均匀的片键会造成某些块的数据量非常大，同样有上面数据分布不均匀，性能瓶颈的问题。
查询带分片查询时建议带上分片，使用分片键进行条件查询时，mongos 可以直接定位到具体分片，否则 mongos 需要将查询分发到所有分片，再等待响应返回。
避免单调递增或递减 单调递增的 sharding key，数据文件挪动小，但写入会集中，导致最后一篇的数据量持续增大，不断发生迁移，递减同理。

综上，在选择片键时要考虑以上 4 个条件，尽可能满足更多的条件，才能降低 MoveChunks 对性能的影响，从而获得最优的性能体验。