MongoDB架构图解

浅浅的花香味﹌ 2021-06-26 16:06 558阅读 0赞

本文图片来自`Ricky Ho`的博文`MongoDB`构架（`MongoDB Architecture`），这是个一听就感觉很宽泛的话题，但是作者在文章中确实对`MongoDB`由内至外的架构进行了剖析。本文截取了其文章中的几张重点架构示意图片进行简单描述。希望对大家有用。

**`MongoDB`数据文件内部结构**  
![在这里插入图片描述][20190901192051953.png]

1.  `MongoDB`在数据存储上按命名空间来划分，一个`collection`是一个命名空间，一个索引也是一个命名空间
2.  同一个命名空间的数据被分成很多个`Extent`，`Extent`之间使用双向链表连接
3.  在每一个`Extent`中，保存了具体每一行的数据，这些数据也是通过双向链接连接的
4.  每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据`update`变大后可以不移动位置
5.  索引以`BTree`结构实现

**在`MongoDB`中实现事务**  
![在这里插入图片描述][20190901192253311.png]众所周知，`MongoDB`只支持对单行记录的原子性修改，并不支持对多行数据的原子操作。但是通过上图中的变态操作，实际你也可以自己实现事务。其步骤如图所未：

*  第1步：先记录一条事务记录，将要修改的多行记录的修改值写到里面，并设置其状态为`init`（如果这时候操作中断，那么在重新启动时，会判断到他处于`init`状态，从而将其保存的多行修改操作应用到具体的行上）
 *  第2步：然后更新具体要修改的行，将刚才写的事务记录的标识写到它的`tran`字段中
 *  第3步：将事务记录的状态从`init`变成`pending`（如果在这时候操作中断，那么在重新启动时，会判断到它的状态是`pending`的，这时候查看其所有对应的多条要修改的记录，如果其`tran`有值，那么就进行第4步，如果没值，说明第4步已经执行过了，直接将其状态从`pending`变成`commited`了就行）
 *  第4步：将需要修改的多条记录的相应值修改了，并且`unset`掉之前的`tran`字段
 *  第5步：将事务记录那一条的状态从`pending`变成`commited`，事务完成

其实上面的步骤并不罕见，在支持事务的`DBMS`中，其事务原子性提交的保证大多都与上面类似。其实事务记录的`tran`那条记录，就类似于这些`DBMS`中的`redolog`一样。

**`MongoDB`数据同步**  
![在这里插入图片描述][20190901212838196.png]上图是`MongoDB`采用`Replica Sets`模式的同步流程

*  红色箭头表示写操作写到`Primary`上，然后异步同步到多个`Secondary`上
 *  蓝色箭头表示读操作可以从`Primary`或`Secondary`任意一个上读
 *  各个`Primary`与`Secondary`之间一直保持心跳同步检测，用于判断`Replica Sets`的状态

**分片机制**  
![在这里插入图片描述][2019090121305176.png] \- `MongoDB`的分片是指定一个分片`key`来进行，数据按范围分成不同的`chunk`，每个`chunk`的大小有限制

*  有多个分片节点保存这些`chunk`，每个节点保存一部分的`chunk`
 *  每一个分片节点都是一个`Replica Sets`，这样保证数据的安全性
 *  当一个`chunk`超过其限制的最大体积时，会分裂成两个小的`chunk`
 *  当`chunk`在分片节点中分布不均衡时，会引发`chunk`迁移操作

**服务器角色**  
![在这里插入图片描述][20190901213133255.png]上面讲了分片的标准，下面是具体在分片时的几种节点角色

*  客户端访问路由节点`mongos`来进行数据读写
 *  `config`服务器保存了两个映射关系，一个是`key`值的区间对应哪一个`chunk`的映射关系，另一个是`chunk`存在哪一个分片节点的映射关系
 *  路由节点通过`config`服务器获取数据信息，通过这些信息，找到真正存放数据的分片节点进行对应操作
 *  路由节点还会在写操作时判断当前`chunk`是否超出限定大小，如果超出，就分列成两个`chunk`
 *  对于按分片`key`进行的查询和`update`操作来说，路由节点会查到具体的`chunk`然后再进行相关的工作
 *  对于不按分片`key`进行的查询和`update`操作来说，`mongos`会对所有下属节点发送请求然后再对返回结果进行合并

[20190901192051953.png]: /images/20210626/a34869b318634760b4f90215032a53f8.png
[20190901192253311.png]: /images/20210626/c34f3845b261426e9ebd4f48c292b5ab.png
[20190901212838196.png]: /images/20210626/1f0bae273a25443f8c5fbbb90a9e5d6d.png
[2019090121305176.png]: /images/20210626/04d3071add9f4598acf571ced20074f6.png
[20190901213133255.png]: /images/20210626/ea31e705566a4fc99a8bb6432d5d5006.png