<< 返回文章列表

了解 MongoDB 看这一篇就够了(下)

2020年1月8日
美码师
404

五、集群


在大数据领域常常提到的4V特征中,Volume(数据量大)是首当其冲被提及的。由于单机垂直扩展能力的局限,水平扩展的方式则显得更加的靠谱。MongoDB 自带了这种能力,可以将数据存储到多个机器上以提供更大的容量和负载能力。此外,同时为了保证数据的高可用,MongoDB 采用副本集的方式来实现数据复制。

一个典型的MongoDB集群架构会同时采用分片+副本集的方式,如下图:

1578455248157007595.jpg

图-MongoDB 分片集群(Shard Cluster)

架构说明


 · 数据分片(Shards) 分片用于存储真正的集群数据,可以是一个单独的 Mongod实例,也可以是一个副本集。生产环境下Shard一般是一个 Replica Set,以防止该数据片的单点故障。对于分片集合(sharded collection)来说,每个分片上都存储了集合的一部分数据(按照分片键切分),如果集合没有分片,那么该集合的数据都存储在数据库的 Primary Shard中。

 · 配置服务器(Config Servers) 保存集群的元数据(metadata),包含各个Shard的路由规则,配置服务器由一个副本集(ReplicaSet)组成。

 · 查询路由(Query Routers) Mongos是 Sharded Cluster 的访问入口,其本身并不持久化数据 。Mongos启动后,会从 Config Server 加载元数据,开始提供服务,并将用户的请求正确路由到对应的Shard。Sharding 集群可以部署多个 Mongos 以分担客户端请求的压力。


分片机制


下面的几个细节,对于理解和应用 MongoDB 的分片机制比较重要,所以有必要提及一下:

1. 数据如何切分

首先,基于分片切分后的数据块称为 chunk,一个分片后的集合会包含多个 chunk,每个 chunk 位于哪个分片(Shard) 则记录在 Config Server(配置服务器)上。Mongos 在操作分片集合时,会自动根据分片键找到对应的 chunk,并向该 chunk 所在的分片发起操作请求。

数据是根据分片策略来进行切分的,而分片策略则由 分片键(ShardKey)+分片算法(ShardStrategy)组成。

MongoDB 支持两种分片算法:

 · 范围分片


微信图片_20200108111236.jpg

如上图所示,假设集合根据x字段来分片,x的取值范围为[minKey, maxKey](x为整型,这里的minKey、maxKey为整型的最小值和最大值),将整个取值范围划分为多个chunk,每个chunk(默认配置为64MB)包含其中一小段的数据:如 Chunk1 包含x的取值在[minKey, -75)的所有文档,而Chunk2包含x取值在[-75, 25)之间的所有文档…

范围分片能很好的满足范围查询的需求,比如想查询x的值在[-30, 10]之间的所有文档,这时 Mongos 直接能将请求路由到 Chunk2,就能查询出所有符合条件的文档。范围分片的缺点在于,如果 ShardKey 有明显递增(或者递减)趋势,则新插入的文档多会分布到同一个chunk,无法扩展写的能力,比如使用_id作为 ShardKey,而MongoDB自动生成的id高位是时间戳,是持续递增的。

 · 哈希分片


微信图片_20200108111238.jpg

Hash分片是根据用户的 ShardKey 先计算出hash值(64bit整型),再根据hash值按照范围分片的策略将文档分布到不同的 chunk。由于 hash值的计算是随机的,因此 Hash 分片具有很好的离散性,可以将数据随机分发到不同的 chunk 上。Hash 分片可以充分的扩展写能力,弥补了范围分片的不足,但不能高效的服务范围查询,所有的范围查询要查询多个 chunk 才能找出满足条件的文档。

2. 如何保证均衡

如前面的说明中,数据是分布在不同的 chunk上的,而 chunk 则会分配到不同的分片上,那么如何保证分片上的 数据(chunk) 是均衡的呢?在真实的场景中,会存在下面两种情况:

 · A. 全预分配,chunk 的数量和 shard 都是预先定义好的,比如 10个shard,存储1000个chunk,那么每个shard 分别拥有100个chunk。此时集群已经是均衡的状态(这里假定)

 · B. 非预分配,这种情况则比较复杂,一般当一个 chunk 太大时会产生分裂(split),不断分裂的结果会导致不均衡;或者动态扩容增加分片时,也会出现不均衡的状态。这种不均衡的状态由集群均衡器进行检测,一旦发现了不均衡则执行 chunk数据的搬迁达到均衡。

MongoDB 的数据均衡器运行于 Primary Config Server(配置服务器的主节点)上,而该节点也同时会控制 Chunk 数据的搬迁流程。


微信图片_20200108111240.jpg

图-数据自动均衡

对于数据的不均衡是根据两个分片上的 Chunk 个数差异来判定的,阈值对应表如下:

1578455412036054974.png


MongoDB 的数据迁移对集群性能存在一定影响,这点无法避免,目前的规避手段只能是将均衡窗口对齐到业务闲时段。

https://docs.mongodb.com/manual/tutorial/manage-sharded-cluster-balancer/#sharding-schedule-balancing-window

3. 应用高可用

应用节点可以通过同时连接多个 Mongos 来实现高可用,如下:


微信图片_20200108111242.jpg

图- mongos 高可用

当然,连接高可用的功能是由 Driver 实现的。


副本集


副本集又是另一个话题,实质上除了前面架构图所体现的,副本集可以作为 Shard Cluster 中的一个Shard(片)之外,对于规模较小的业务来说,也可以使用一个单副本集的方式进行部署。MongoDB 的副本集采取了一主多从的结构,即一个 Primary Node + N* Secondary Node的方式,数据从主节点写入,并复制到多个备节点。

典型的架构如下:


微信图片_20200108111244.jpg

 · 利用副本集,我们可以实现::

 · 数据库高可用,主节点宕机后,由备节点自动选举成为新的主节点。

读写分离,读请求可以分流到备节点,减轻主节点的单点压力。

请注意,读写分离只能增加集群”读”的能力,对于写负载非常高的情况却无能为力。对此需求,使用分片集群并增加分片,或者提升数据库节点的磁盘IO、CPU能力可以取得一定效果。


选举

MongoDB 副本集通过 Raft 算法来完成主节点的选举,这个环节在初始化的时候会自动完成,如下面的命令:

config = {

    _id : "my_replica_set",

    members : [

        {_id : 0, host : "rs1.example.net:27017"},

        {_id : 1, host : "rs2.example.net:27017"},

        {_id : 2, host : "rs3.example.net:27017"},

  ]

}

rs.initiate(config) 

initiate 命令用于实现副本集的初始化,在选举完成后,通过 isMaster()命令就可以看到选举的结果:

> db.isMaster()

{

    "hosts" : [

    "192.168.100.1:27030",

    "192.168.100.2:27030",

    "192.168.100.3:27030"

    ],

    "setName" : "myReplSet",

    "setVersion" : 1,

    "ismaster" : true,

    "secondary" : false,

    "primary" : "192.168.100.1:27030",

    "me" : "192.168.100.1:27030",

    "electionId" : ObjectId("7fffffff0000000000000001"),

    "ok" : 1

受 Raft算法的影响,主节点的选举需要满足”大多数”原则,可以参考下表:

1578455587940095611.png

因此,为了避免出现平票的情况,副本集的部署一般采用是基数个节点,比如3个,正所谓三人行必有我师..

心跳

在高可用的实现机制中,心跳(heartbeat)是非常关键的,判断一个节点是否宕机就取决于这个节点的心跳是否还是正常的。副本集中的每个节点上都会定时向其他节点发送心跳,以此来感知其他节点的变化,比如是否失效、或者角色发生了变化。利用心跳,MongoDB 副本集实现了自动故障转移的功能,如下图:


微信图片_20200108111246.jpg

默认情况下,节点会每2秒向其他节点发出心跳,这其中包括了主节点。如果备节点在10秒内没有收到主节点的响应就会主动发起选举。此时新一轮选举开始,新的主节点会产生并接管原来主节点的业务。整个过程对于上层是透明的,应用并不需要感知,因为 Mongos 会自动发现这些变化。如果应用仅仅使用了单个副本集,那么就会由 Driver 层来自动完成处理。

复制

主节点和备节点的数据是通过日志(oplog)复制来实现的,这很类似于 mysql 的 binlog。在每一个副本集的节点中,都会存在一个名为local.oplog.rs的特殊集合。当 Primary 上的写操作完成后,会向该集合中写入一条oplog, 而 Secondary 则持续从 Primary 拉取新的 oplog 并在本地进行回放以达到同步的目的。

下面,看看一条 oplog 的具体形式:

{

"ts" : Timestamp(1446011584, 2),

"h" : NumberLong("1687359108795812092"),

"v" : 2,

"op" : "i",

"ns" : "test.nosql",

"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }

}

其中的一些关键字段有:

 · ts 操作的 optime,该字段不仅仅包含了操作的时间戳(timestamp),还包含一个自增的计数器值。

 · h 操作的全局唯一表示

 · v oplog 的版本信息

 · op 操作类型,比如 i=insert,u=update..

 · ns 操作集合,形式为 database.collection

 · o 指具体的操作内容,对于一个 insert 操作,则包含了整个文档的内容

 · MongoDB 对于 oplog 的设计是比较仔细的,比如:

 · oplog 必须保证有序,通过 optime 来保证。

 · oplog 必须包含能够进行数据回放的完整信息。

 · oplog 必须是幂等的,即多次回放同一条日志产生的结果相同。

 · oplog 集合是固定大小的,为了避免对空间占用太大,旧的 oplog 记录会被滚动式的清理。

有兴趣的读者,可以参考官方文档:

https://docs.mongodb.com/manual/core/replica-set-oplog/index.html


六、事务与一致性


一直以来,“不支持事务” 是 MongoDB 一直被诟病的问题,当然也可以说这是 NoSQL 数据库的一种权衡(放弃事务,追求高性能、高可扩展) 但实质上,MongoDB 很早就有事务的概念,但是这个事务只能是针对单文档的,即单个文档的操作是有原子性保证的。在4.0 版本之后,MongoDB 开始支持多文档的事务:

 · 4.0 版本支持副本集范围的多文档事务。

 · 4.2 版本支持跨分片的多文档事务(基于两阶段提交)。

在事务的隔离性上,MongoDB 支持快照(snapshot)的隔离级别,可以避免脏读、不可重复读和幻读。尽管有了真正意义上的事务功能,但多文档事务对于性能有一定的影响,应用应该在充分评估后再做选用。

一致性


一致性是一个复杂的话题,而一致性更多从应用角度上提出的,比如:

向系统写入一条数据,应该能够马上读到写入的这个数据。

在分布式架构的CAP理论以及许多延续的观点中提到,由于网络分区的存在,要求系统在一致性和可用性之间做出选择,而不能两者兼得。


1578455761902016123.jpg

图 -CAP理论

在 MongoDB 中,这个选择是可以由开发者来定的。MongoDB 允许客户端为其操作设定一定的级别或者偏好,包括:

 · read preference 读取偏好,可指定读主节点、读备节点,或者是优先读主、优先读备、取最近的节点

 · write concern 写关注,指定写入结果达到什么状态时才返回,可以为无应答(none)、应答(ack),或者是大多数节点完成了数据复制等等

 · read concern 读关注,指定读取的数据版本处于怎样的状态,可以为读本地、读大多数节点写入,或者是线性读(linearizable)等等。

使用不同的设定将会产生对于C(一致性)、A(可用性)的不同的抉择,比如:

 · 将读偏好设置为 primary,此时读写都在主节点上。这保证了数据的一致性,但一旦主节点宕机会导致失败(可用性降低)

 · 将读偏好设置为 secondaryPrefered,此时写主,优先读备,可用性提高了,但数据存在延迟(出现不一致)

 · 将读写关注都设置为 majority(大多数),一致性提升了,但可用性也同时降低了(节点失效会导致大多数写失败)

关于这种权衡的讨论会一直存在,而 MongoDB 除了提供多样化的选择之外,其主要是通过复制、基于心跳的自动failover等机制来降低系统发生故障时产生的影响,从而提升整体的可用性。


小结


本文主要揭示了 MongoDB 多个方面的细节,同时在使用体验上也借助 SQL 的概念做了一些对比。从笔者的角度看,MongoDB 的发展性是很强的,其灵活快速的开发模式、天生自带分布式等能力弥补了传统型SQL数据库的缺陷。当然,目前的 NewSQL 本质上也貌似在以”模仿的方式”弥补这些缺陷。

希望本文的内容对你能有些参考。