mongodb 5.0.4 分片集群部署

一、MongoDB 背景

MongoDB 是一款功能完善的分布式文档数据库，是一款非常出名的 NoSQL 数据库。当前国内使用 Mongodb 的大型实践越来越多，MongoDB 为我司提供了重要的数据库存储服务，支撑着每天近千万级 QPS 峰值读写，数万亿级数据量存储服务。

MongoDB 在高性能、动态扩缩容、高可用、易部署、易使用、海量数据存储等方面拥有很大优势。近些年，MongoDB 在 DB-Engines 流行度排行榜稳居榜单 Top5 ，且历年得分是持续增长的，具体如下图所示：

DB-Engines 是一个对数据库管理系统受欢迎程度进行排名的网站。排名分数：MongoDB 是 Top5 内的唯一的非关系型数据库。我们今天从比较高的层面来观摩学习下 MongoDB 的几种高可用架构。通过观察这几种架构我们甚至能体会到通用的分布式架构的一个演进方向。

二、高可用架构

高可用性 HA（High Availability）指的是缩短因正常运维或者非预期故障而导致的停机时间，提高系统可用性。

那么问题来了，都说自己的服务高可用，高可用能量化衡量吗？能不能比出个高低呢？

可以，这里引出一个 SLA 的概念。SLA 是 Service Level Agreement 的缩写，中文含义：服务等级协议。SLA 就是用来量化可用性的协议，在双方认可的前提条件下，服务提供商与用户间定义的一种双方认可的协定。SLA 是判定服务质量的重要指标。

问题来了，SLA 是怎么量化的？其实就是按照停服时间算的。怎么算的？举个例子：

1 年 = 365 天 = 8760 小时
99.9 停服时间：8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 停服时间：8760 * 0.0001 = 0.876 小时 = 52.6 分钟
99.999 停服时间：8760 * 0.00001 = 0.0876 小时 = 5.26分钟

也就是说，如果一家公有云厂商提供对象存储的服务，SLA 协议指明提供 5 个 9 的高可用服务，那就要保证一年的时间内对象存储的停服时间少于 5.26 分钟，如果超过这个时间，就算违背了 SLA 协议，可以找公有云提出赔偿。

说回高可用的话题，大白话就是，无论出啥事都不能让承载的业务受影响，这就是高可用。

前面我们说过，无论是数据的高可靠，还是组件的高可用全都是一个解决方案：冗余。我们通过多个组件和备份导致对外提供一致性和不中断的服务。冗余是根本，但是怎么来使用冗余则各有不同。

以下我们就按照不同的冗余处理策略，可以总结出 MongoDB 几个特定的模式，这个也是通用性质的架构，在其他的分布式系统也是常见的。

我们从 Mongo 的三种高可用模式逐一介绍，这三种模式也代表了通用分布式系统下高可用架构的进化史，分别是 Master-Slave，Replica Set，Sharding 模式。

Master-Slave 模式

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

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

Master-Slave 由主从角色构成：

Master ( 主 )

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

Slave ( 从 )

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

如图：

通过上面的图，这是一种典型的扇形结构。

Master-Slave 对读写分离的思考
Master 对外提供读写服务，有多个 Slave 节点的话，可以用 Slave 节点来提供读服务的节点。

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

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

Master-Slave 对容灾的思考
当 Master 节点出现故障的时候，由于 Slave 节点有备份数据，有数据就好办呀。只要有数据还在，对用户就有交代。这种 Master 故障的时候，可以通过人为 Check 和操作，手动把 Slave 节点指定为 Master 节点，这样又能对外提供服务了。

思考下这种模式有什么特点？

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

最大的第一个问题就是可用性差。因为很容易理解，因为主节点挂掉的时候，必须要人为操作处理，这里就是一个巨大的停服窗口；

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

怎么搭建 Master-Slave 模式？

启动 Master 节点：

mongod –master –dbpath /data/masterdb/

关键参数：

–master ：指定为 Master 角色；
启动 Slave 节点：

mongod –slave –source <:> –dbpath /data/slavedb/

关键参数：

–slave ：指定为 Slave 角色；
–source ：指定数据的复制来源，也就是 Master 的地址；

Replica Set 副本集模式

Replica Set 模式角色
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 可以减轻在减少数据的冗余备份，又能提供高可用的能力。

如下图：