开发者学堂课程【MongoDB 快速入门：分片集群使用及原理介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/49/detail/1003
分片集群使用及原理介绍（二）
三、Chunk&Balancer
上面了解到的是分片键，即数据是如何进行拆分的。Chunk&Balancer 主要是MongoDB 在底层如何进行数据管理的，下面进行学习什么是 Chunk，Chunk 的分裂与迁移以及自动迁移的触发器balancer，另外就是 JumboChunk 引入的一些特性。
1、什么是 Chunk
经过前面的学习对Chunk有一个初步的了解。MongoDB基于shardkey将collection拆分为多个数据子集，每个子集称为一个Chunk。已经分片的集合的数据按照shardkey划分为minkey~maxkey的区间。每个Chunk有自己负责的区间，区间是前闭后开的。存储了分片的集合的shark上有该集合的一个或多个Chunk。由图可知分片的集合是基于x的范围分片，数据被分成了四个chunk，chunk1到chunk4分别是由{minkey,-75},{75,25},{25,175},{75,maxkey}的前闭后开的区间。shardA是持有chunk1和chunk2，而ShardB和ShardC分别持有chunk3和chunk4。
2、chunk 分裂
伴随着数据的写入，当Chunk增长到指定大小时，MongoDB会对Chunk进行分裂，称为ChunkSplit。指定大小默认为64MB。Chunk分裂有两种方式，一种是上面提到的自动触发的方式，一种是手动的触发。手动触发会用到sh命令集的sh.splitAt和sh.splitFind两个子命令。自动触发则是伴随着数据的插入和更新来进行的。需要注意的是当chunkSize被调小时，不会立即生成chunkSplit。JumboChunk是什么，一个最小的Chunk可以包含一个唯一的Shardkey，这样的chunk不可以在进行分裂，称为JumboChunk。
3、Chunk 分裂管理
Chunk分裂的干预手段，Chunk分裂的管理手段首先自动的Chunk分裂可以满足大多数的需求，但是仍然有场景需要手动进行Chunk分裂，比如业务需要向集合中插入大量的数据，而这些数据只分布在较少的Chunk中，直接插入无法利用到多shard并发写入的特点，而且插入后触发chunk分裂，进而触发Chunk迁移，产生很多无效IO。手动进行Chunk分裂，引发Chunk迁移，将Chunk在集群中打散，就可以解决上面的问题。比如指定splitAt，这是chunk分裂点的触发逻辑，如果有一个chunk是[0,100)，指定{x:70},执行splitAt之后，chunk就会被分裂为[0,70),[70,100)。splitFind则是从中间分裂chunk，同样的x=70的query语句，chunk就会被分裂成[0,50),[50,100)。另外还有场景会调整chunksize，这里给出调整chunksize的方式，是对config库的setting集合，增加文档，文档的ID为chunksize。需要注意只有在插入和更新的时候操作才会触发对应Chunk分裂--调小ChunkSize不会立即触发所有Chunk分裂为新的大小。另外ChunkSize取值范围是1到1024MB。调小ChunkSize可以让Chunk更均衡的分布，但是Chunk迁移次数会增加。调大ChunkSize会减少Chunk迁移，但会导致Chunk分布不均。
4、Chunk 的迁移
为了保证数据负载均衡，MongoDB支持Chunk在Shard间迁移，称为Chunk Migration。Chunk迁移和Chunk分裂一样支持两种方式，首先是自动触发：当Chunk在Shard之间分布不均时，Balancer会自动触发Chunk迁移。另外是手动触发，可以执行sh.moveChunk,指定目标的collection，指定chunk以及目标的shard进行迁移。Chunk的迁移会导致shard之间的数据大小发生变化，同时会增加网络带宽和系统负载，这些都会对系统的性能造成影响。Chunk迁移也存在一些约束，每个shard同一时间只能有一个Chunk在进行迁移，不会迁移Chunk中文档数量是平Chunk文档数1.3倍的Chunk，这个限制在4.4中也提供了选项支持。可以迁移这样的Chunk
5、Balancer
之前提到自动迁移是要由系统当中的Balancer进程进行触发的，Balancer是MongoDB的一个后台进程，用保证集合的Chunk在各个Shard上是均衡的。Balancer运行在ConfigServer的Primary节点，默认为开启状态。当分片集群中发生Chunk不均衡的情况，比如触发到了某一个阈值，Balancer将触发Chunk从Chunk数量最多的Shard像Chunk数量最少的Shard迁移。比如Chunk的数量小于20，迁移的阈值为2，Chunk的数量增大，迁移阈值会分别增长为4和8
6、AutoSplit&Balancer 管理命令
可以自主的开启或关闭Chunk的自动分裂，使用到的是enableAutoSplit和disableAutoSplit。可以通过getBalancerState和isBalancerRunning查看Balancer是否开启以及Balancer是否正在运行。开启和关闭Balancer可以通过startBalancer和stopBalancer。当4.2版本开始，这两个命令会同时开启AutoSplit。还可以控制开启、关闭某个集合自动迁移使用enableBalancing和disableBalancing。最后还可以调整Balancer的运行窗口，同样是对config库的setting集合添加一条ID为balancer的文档来指定他的时间窗口，比如说需要凌晨两点到六点来运行balancer的触发chunk迁移就会用到这样的方式。
7、JumboChunk
现在学习JumboChunk引入的一些特性和问题。一个最小的chunk可以包含一个唯一的shardkey，这样的Chunk不可以在进行分裂，称为JumboChunk。首先JumboChunk的产生大概因为shardkey选用不合理，才会产生JumboChunk，如果JumboChunk是高频访问的就会引起单shard的性能瓶颈。JumboChunk是不可以在进行迁移的，也会引起shard之间的数据不均衡。随着MongoDB的版本迭代，这些问题也在逐步的被解决，比如在4.4版本中，重新设定了refineCollectionSharkey的命令，可以重新设定shardkey，同时4.4中也给balancer提供了一些设置，给moveChunk提供了一些option支持chunk的迁移，在4.2和4.0的较新的小版本中也提供了命令，来提供集群中的JumboChunk标识。
四、集群管理
先回顾一下上面学到的命令，另外学习一下集群状态查看叫做sh.status，另外了解一下logicalSession的相关特性。
1、命令回顾
首先之前学习了很多关于sh的命令，将它们分为三个部分，分别是Balancer、Chunk、Sharding。在Balancer当中可以开关Balancer，查看Balancer是否开启，是否运行以及关闭和开启Balancer对某一stage的迁移。在Chunk当中，可以开关AutoSplit，可以手动的进行moveChunk。最后就是最开始学到的使用enableSharding和shardCollection对集合进行分片。
2、集群状态查看-sh.status
进一步的对集群状态进行查看，使用到的是sh.status。通过截图可以看到sharding的版本信息，可以看到分片集群的版本信息，也可以看到分片集群中目前有两个shard，每个shard的名称、链接信息以及shard的当前状态，下面可以看到目前集群发片中有两个4.2.1版本的mongos。随后可以看到autosplit和balancer的一些信息，当前是开启auto-split，balancer状态为开启，但是目前没有在运行。可以看到过去一段时间balancer执行的成功、失败信息。再往下是所有标识sharding状态的database，和已经分片的集合的信息。
从这里可以看到有一个records库，它的primary是shard的信息，以及当前是开启sharding的。另外一些database的版本信息。对于records库下面的people集合，是一个基于zipcode的hashed分片，无须unique约束的，balancer可以针对该集合进行数据迁移，集合有4个chunk，平均分配在2个shard上，可以看到chunk所负责的范围以及所属的shard
3、LogicalSession
最后看一下3.6当中，新增加的LogicalSession的特性。3.6版本开始，MongoDB driver将所有的操作与LogicalSession关联。在3.4版本及以前 比如客户端发送请求给mongos，mongos会在自身建立cursor，并向后端发起find的请求，在后端建立相对应的cursor，这时假设mongos发生了故障，恰巧cursor指定的是not，i am not，cursor会长时间的保留下去，而且对movechunk产生影响，同时也没有很好的方式管理cursor。在3.6版本开始所有的operation,所有的cursor都跟LogicalSession进行关联，在刚才提到的情况，client可以通过连接mongosB的方式和mongosB进行交互，查看使用LogicalSession的命令，比如list session 和kill session来进行session的查看。LogicalSession实际上基于LogicalSession ID的文档来进行实现的。LogicalSession 的ID是由两部分组成首先是一个ID字段，这是唯一标识，这个字段可以由客户端生成，也可以由服务端生成。如果由客户端生成可以减少在服务端生成的一些性能影响。第二个字段是UUID，是当前登陆用户的标识。LogicalSession 是持久存储在config.system.sessions集合当中，这个集合有一个TTL索引，默认是30分钟，也就是如果LogicalSession 超过30分钟没有运行，session超过30分钟都不活跃，session将会被杀死。而各个节点是每五分钟和config.system.sessions集合进行同步的，来关闭已经被清理得session，同时关闭session上的cursor。下面也提供了LogicalSession的使用方式，比如可以对config.system.sessions集合进行聚合的运算，指定$listSession的stage来查看分片集群当中的session信息，这里由于指定了allUsers:ture,所有用户的session信息，默认状态下这能查看到当前用户的session信息，也可以通过killsession的命令来杀死一个到多个的session。另外MongoDB还提供了startSession、refershSessions和endSessions的命令来帮助更加灵活的运用LogicalSession。
总结一下本节课一共了解了四部分的内容，在分片集群的基本架构中，了解了分片集群的基本架构，如何对集合进行分片。在分片键中了解了分片键的两种形式：范围分片和哈希分片，分片键的选择与约束，基于分片键的请求分发。在第三部分中，了解到了什么是 chunk，chunk 分裂，chunk 迁移以及 jumbochunk 引入的一些问题和解决方案。最后一部分了解集群状态如何查看以及3.6当中新增的 LogicalSessio n的一些特性。本节课的学习到此结束，如有问题可以到群里提问。
