《一起学mongodb》之第二卷部署模式(一)

微号：「moon聊技术」
关注选择“ 「星标」 ”， 重磅干货，第一 时间送达！
[如果你觉得文章对你有帮助，欢迎「关注，在看，点赞，转发」]

前言

上一篇跟大家简单的介绍了一下 mongoDB 的特点，做了一个简单的入门，不知道大家是否还记得，不记得的小伙伴可以回顾一下 《一起学》mongodb 之第一卷

今天就主要和大家来聊一聊 「mongoDB 的单点模式、主从模式和副本集模式」，分片集群由于也是很重点一块儿，并且内容较多，我会把他放在下一篇内容和大家聊聊

单机模式

第一种模式也叫做单机模式，它「是最基本的一种模式」，无数的数据库的雏形都是这种方式。

这种部署方式只含有一个 mongod 实例。这种部署方式最简单，但是它并没有数据备份，一旦该节点出现故障，很难快速切换到其他节点，当数据损坏的时候可能会丢失数据，一般不建议采用这种方式。

主从模式

「master」:主节点，负责数据的读写工作
「slave」:从节点，只负责数据的读工作

image

主从模式也是集群部署中最常见的方式之一，比如 mysql，redis 都支持主从的部署方式，「主要用于备份，故障恢复，读扩展，读写分离」.

image

「主从同步流程：」

• 1.主节点接受用户的写请求，更新用户表和oplog表。「如果用户设置了 writeConcern 属性」，则可能开启了写确认，处理线程可能会阻塞
• 2.从节点上的后台线程到主节点上「获取 oplog」，并「放入到 OplogBuffer中」
• 3."replBatcher" 「从 OplogBuffer 中消费并保存到 OpQueue 中」
• 4."OplogApplier" 线程通过多个（默认16个）worker 线程「从 OpQueue 获取数据并回放 Oplog」，并更新 lastAppliedOpTime 和 lastDurableOpTime
• 5.从节点上的后台线程感知到有新数据写入成功，「将自身最新的 lastAppliedOpTime和lastDurableOpTime 等信息返回给主节点」
• 6.主节点「接受」到各个从节点最新的 「lastAppliedOpTime 和 lastDurableOpTime」，计算大多数节点当前的数据同步进展，并「更新 lastCommittedOpTime」, 然后唤醒正在等待的请求处理线程主节点上的用户处理线程给用户返回处理结果

image

总的来说 ，mongoDB 的 slave 节点之间是无感知的，在 master 收到写请求后，会将该信息「写入到 oplog」 中，「oploog 是一个固定大小的文件」，slave 会「定时拉取 oplog」，来完成数据的同步，这是属于「增量同步」

当然还有两种情况是全量同步

• 新 slave 节点进入
• slave 节点数据落后太多(slave 节点的最新数据时间戳小于 oplog 最老数据的时间戳)

mongoDB 主从模式的特点:

• Master-Slave 的角色是静态配置的，不能自动切换角色，必须人为指定；
• 用户只能写 Master 节点，Slave 节点只能从 Master 拉数据；
• Slave 节点只和 Master 通信，Slave 之间相互不感知，
• 读写分离

image

缺点：

• 系统明显存在单点，那么多 Slave 只能从 Master 拉数据，而无法提供自己的判断；
• 在主从模式下如果 master 挂了，「只能手工完成故障恢复，无法自动完成故障转移」
• 可用性差。因为主节点挂掉的时候，必须要人为操作处理
• 短期的数据不一致问题，对于必须需要数据强一致的场景是不合适这种读写分离的
• master 同步压力较大，slave 都要从 master 去同步

副本集模式

我们前面说到了主从模式的一系列缺点，那么副本集模式就是优化了它的一系列缺点

我们先来介绍一下副本集模式

image

副本集模式的角色除了 「master(也可以叫做 primary)」 和 「slave(也可以的叫做 Secondary)」 之外，还多了一个 「arbiter」(仲裁者)，仲裁节点「没有数据集的副本」，并且「不能成为主节点」。然而，仲裁节点「可以参与主节点选举」。一个仲裁节点只有 1 票选举权。

选举 master

slave 之间会间歇性的「发送心跳包来维护各个节点的信息」，节点根据自己的集群状态判断是否需要更新新的 primary。在实现的时候主要由两个异步的过程分别处理心跳响应和超时，每个复制集成员都会在后台运行与复制集所有节点的心跳线程，在以下几种情况下会触发状态检测过程：

• slave 节点权重(Priority)比 master 节点高
• slave 节点发现集群中没有 master 时
• master 节点不能访问到大部分成员时主动降级，降级操作会断开连接，终止用户请求
• 复制集成员心跳检测结果发生变化，比如某个节点挂了或者新增节点，发起重新投票选举规则
• 超过4s没有执行状态检测过程

「选举发起」 发起选举的节点首先需要做一些条件判断，维护主节点的有 N 个备用节点，备用节点中的所有节点都可能被选举成为主节点，成为主节点前每个备节点都会检测自身以及全局条件是否满足，检测条件如下：

• 是否看见复制集中是否有 majority 在线
• priority 是否大于0
• 不为 arbiter
• 同步进度不能落后于最新节点 10s 以上
• 存储的集群信息为最新

如果所有条件满足，则将自身添加到主节点的备用列表中，否则，将自身从列表中移除

「自身检测」

• MongoDB 选举需要获得大多数投票才能通过，如果没有节点投反对票，且获得成票数超过有权投票节点总数的1/2，则能成为 Primary。否则进入下一轮选举。为避免陷入无限重复选举，MongoDB 建议复制集的成员个数为奇数，当 Secondary 为双数时，可以增加一个 Arbiter 节点。
• 选举过程中，复制集没有主节点，所有成员都是只读状态
• 选举过程很复杂，一般情况下需要 5s 左右进行选主。
• 如果新选择的主节点立刻挂掉，至少需要 30s 时间重新选主。

同步数据

image

「初始化同步源的选择」（全量）

初始化同步源的选择取决于启动参数 「initialSyncSourceReadPreference」：

• primary （禁用级联后的默认值），则选择主节点作为同步源。如果主服务器不可用或无法访问，则记录错误并定期检查主服务器的可用性。
• primaryPreferred，则优先尝试选择主节点作为同步源。如果主节点不可用或者无法访问，则将从剩余可用的副本集成员中选择同步源。
• secondary:操作只能从集合的次要成员中读取。如果没有可用的辅助节点，则此读取操作会产生错误或异常。
• secondaryPreferred:在大多数情况下，操作从辅助成员中读取，但在该集合由单个 主成员（并且没有其他成员）组成的情况下，读取操作将使用副本集的主成员。
• nearest （启用级联后的默认值），则从副本集成员中选择网络时延最小的节点最为同步源。

执行初始化同步源选择的成员将「会遍历所有副本集成员的列表两次」：

• 第一次遍历

  • 当为选择复制同步源进行第一次遍历时，执行同步源选择的成员将检查每个副本集成员是否满足如下条件：
  • 同步源必须处于 PRIMARY 或者 SECONDARY 的复制状态。
  • 同步源必须是在线且可访问的。
  • 同步源必须比该成员具有更新的oplog条目（即同步源数据同步领先于该成员）。
  • 同步源必须是可见的。
  • 同步源必须和主节点最新的oplog条目同步时间相差在30s之内。
  • 如果该成员是可创建索引的，则同步源也必须可创建索引。
  • 如果该成员可参与副本集选举投票，则同步源也必须具有投票权。
  • 如果该成员不是一个延迟成员，则同步源也不能是延迟成员。
  • 如果该成员是一个延迟成员，则同步源必须配置一个更短的延迟时间。
  • 同步源必须比当前最好的同步源更快(即更低的时延)。
  • 「如果第一次遍历没有产生候选的同步源，则该成员会用更宽松的条件进行第二次遍历。请参考同步源选择」第二次遍历。

• 第二次遍历

  • 当为选择复制同步源进行第二次遍历时，执行同步源选择的成员将检查每个副本集成员是否满足如下条件：
  • 同步源必须处于 PRIMARY 或者 SECONDARY 的复制状态。
  • 同步源必须是在线且可访问的。
  • 如果该成员是可创建索引的，则同步源也必须可创建索引。
  • 同步源必须比当前最好的同步源更快(即更低的时延)。
  • 「如果该成员在两次遍历后依然无法选择出初始同步源，它会记录报错并在等待1s后重新发起选择的过程」

复制同步源的选择 (增量)

复制同步源的选择取决于副本集参数 chaining 的设置：

• 启用后从副本集成员间执行同步源选择。
• 禁用后选择主节点作为复制源。

执行复制同步源选择的成员将会「遍历」所有副本集成员的列表「两次」：

• 同步源选择（第一次） - 当为选择复制同步源进行第一次遍历时，执行同步源选择的成员将检查每个副本集成员是否满足如下条件： - 同步源必须处于 PRIMARY 或者 SECONDARY 的复制状态。 - 同步源必须是在线且可访问的。 - 同步源必须比该成员具有更新的oplog条目（即同步源数据同步领先于该成员）。 - 同步源必须是可见的。 - 同步源必须和主节点最新的oplog条目同步时间相差在30s之内。 - 如果该成员是可创建索引的，则同步源也必须可创建索引。 - 如果该成员可参与副本集选举投票，则同步源也必须具有投票权。 - 如果该成员不是一个延迟成员，则同步源也不能是延迟成员。 - 如果该成员是一个延迟成员，则同步源必须配置一个更短的延迟时间。 - 同步源必须比当前最好的同步源更快(即更低的时延)。

如果「第一次遍历没有产生候选的同步源」，则该成员会用更宽松的条件「进行第二次遍历」

• 同步源选择（第二次遍历） - 当为选择复制同步源进行第二次遍历时，执行同步源选择的成员将检查每个副本集成员是否满足如下条件： - 同步源必须处于 PRIMARY 或者 SECONDARY 的复制状态。 - 同步源必须是在线且可访问的。 - 如果该成员是可创建索引的，则同步源也必须可创建索引。 - 同步源必须比当前最好的同步源更快(即更低的时延)。 - 如果该成员在两次遍历后依然无法选择出初始同步源，它会记录报错并在等待1s后重新发起选择的过程。

image

MongoDB通过使用「多线程批量应用写操作来提高并发」。MongoDB根据文档 id 进行分批，同时使用不同的线程应用每组操作。MongoDB总是「按照原始的写顺序对给定的文档应用写操作」。

image

「选择从从节点复制数据就叫做链式复制」，

链式复制带来的「好处」是：

• 不用所有从节点都到主节点同步数据，可以有效减少主节点的压力。
• 对于写完主节点即返回，并读主节点的业务来说，开启链式复制能在一定程度上提升性能。

链式复制带来的「缺陷」是：

• 数据复制的链路变长。对于 WriteConcern 设置比较大的请求，处理时长会变长。
• 读oplog的压力从主节点转移到了部分从节点上，会一定程度上影响从节点的性能。

流控制

image

我们知道磁盘文件级别的「读写操作是不能进行」的，所以也就是说，当 mongoDB 收到大量的写请求写入 oplog 后，由于数据量大，则从节点拉取 oplog 可能会造成长时间阻塞，那么就有可能造成「主从不一致」的显现出现

mongoDB 为了减少「主从不一致」这种情况，从 MongoDB 4.2 开始，管理员可以「限制主节点应用其写操作的速度」，目的是将大多数提交延迟保持在可配置参数的最大值之下，从而保证主从之间的一致性。

总结

看完了上述的内容，你应该要知道 「mongoDB 单机、复制、副本集三种模式的区别，主从同步流程，日志同步技术，为什么会有流控制，初始化同步和增量同步是怎么做的?」

其实除了这三种方式以外，还有第四种部署方式-「分片集群」，但是由于分片集群的内容比较多，所以我就放到下一章单独去讲了，下一章见~~

「喜欢的朋友可以给 moon 来个星标，有文章都会第一时间推送给你，点击下方moon 的公众号，关注后右上角点开就可以了看到了，欢迎大家一起讨论」