【MongoDB】— CentOS76部署mongodb分片集群
1、MongoDB分片
1.1 为什么需要Sharded cluster？
MongoDB目前3大核心优势：灵活模式+ 高可用性 + 可扩展性。通过Json文档格式来实现灵活模式，通过复制集来保证高可用，通过Sharded cluster来保证可扩展性。
分片技术，使得集合中的数据分散到多个分片集中。使得MongoDB具备横向的发展。
1.2 何时使用分片技术
- 存储容量需求超出单机磁盘容量
- 活跃的数据集超出单机内存容量，导致很多请求都要从磁盘读取数据，影响性能
- 写IOPS超出单个MongoDB节点的写服务能力
1.3 分片概述
- 当数据量比较大的时候，我们需要把数分片运行在不同的机器中，以降低CPU、内存和Io的压力，Sharding就是数据库分片技术。
- MongoDB分片技术类似MySQL的水平切分和垂直切分，数据库主要由俩种方式做Sharding：垂直扩展和横向切分。
- 垂直扩展的方式就是进行集群扩展，添加更多的CPU，内存，磁盘空间等。
-
横向切分则是通过数据分片的方式，通过集群统一提供服务。
image.png
2 MongoDB分片架构原理
2.1 分片组成
Sharded cluster 组成：Shard、Mongos和Config server 3个组件构成。
image.png
Mongos是Sharded cluster的访问入口，
Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server
而用户的数据则会分散存储到各个shard。Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。
2.2 MongoDB分片架构中的角色
1、数据分片（Shards）
用来保存数据，保证数据的高可用性和一致性。可以是一个单独的mongod实例，也可以是一个副本集。在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合：
image.png
2、查询路由（Query Routers）
路由就是mongos的实例，客户端直接连接mongos，由mongos把读写请求路由到指定的Shard上去。
一个Sharding集群，可以有一个mongos，也可以有多个mongos以减轻客户端请求的压力。
3、配置服务器（Config servers）
保存集群的元数据（metadata），包含各个Shard的路由规则。
总结：
1、配置服务器。是一个独立的mongod进程，保存集群和分片的元数据，即各分片包含了哪些数据的信息。最先开始建立，启用日志功能。像启动普通的mongod一样启动配置服务器，指定configsvr选项。不需要太多的空间和资源，配置服务器的1KB空间相当于真是数据的200MB。保存的只是数据的分布表。当服务不可用，则变成只读，无法分块、迁移数据。
2、 路由服务器。即mongos，起到一个路由的功能，供程序连接。本身不保存数据，在启动时从配置服务器加载集群信息，开启mongos进程需要知道配置服务器的地址，指定configdb选项。
3、分片服务器。是一个独立普通的mongod进程，保存数据信息。可以是一个副本集也可以是单独的一台服务器。
2.4 Sharding分片技术（混合模式）高可用方案的架构图
image.png
3 数据读写流程
3.1 Sharding分片技术（混合模式）高可用架构下MongoDB数据写入流程
image.png
写入流程：
第一步：客户端访问路由服务器（Mongos），路由服务器接收到请求。
第二步：路由服务器将客户端访问配置服务器，配置服务器（Config）根据根据请求信息将数据信息写入到元数据中。
第三步：配置服务器将根据自身记录的元数据信息，指定数据存储位置，并将元数据信息（数据存储位置）返回给路由服务器。
第四步：路由服务器根据Config服务器返回的配置信息，将数据存储到mongod中（数据存储服务器）。存储服务器对数据进行备份和分片存储。
3.2 高可用集群下从MongoDB读取数据流程
image.png
读取数据流程：
第一步：Mongos接受客户端请求，根据并判断请求是否合理（数据库地址是否正确，连接数是否超过最大）
第二步：路由服务器与客户端建立连接，并根据请求信息，去Config服务器中查询元数据信息。
第三步：config服务器将数信息返回给路由服务器。
第四步： config服务器根据元数据信息（数据存储位置），去MongoD服务器中，查询数据。
第五步：数据服务器将数据查询结果返回给路由服务器。
4 数据分布策略
分片支持单个集合的数据分散在多个分片上。目前主要有两种数据分片的策略。
范围分片（Range based sharding）
hash分片（Hash based sharding）
4.1 范围分片策略
image.png
如图，集合是根据字段来进行分片。根据字段的范围不同将一个集合的数据存储在不同的分片中。 在同一个Shard上，每个Shard可以存储很多个chunk，chunk存储在哪个shard的信息会存储在Config server种，mongos也会根据各个shard上的chunk的数量来自动做负载均衡。 范围分片适合满足在一定范围内的查找，例如查找X的值在【100-200】之间的数据，mongo 路由根据Config server中存储的元数据，可以直接定位到指定的shard的Chunk中 缺点 如果shardkey有明显递增（或者递减）趋势，则新插入的文档多会分布到同一个chunk，无法扩展写的能力
4.2 Hash分片
Hash分片是根据用户的shard key计算hash值（64bit整型），根据hash值按照『范围分片』的策略将文档分布到不同的chunk
image.png
优点：Hash分片与范围分片互补，能将文档随机的分散到各个chunk，充分的扩展写能力，弥补了范围分片的不足，
缺点：但不能高效的服务范围查询，所有的范围查询要分发到后端所有的Shard才能找出满足条件的文档。
合理的选择shard key
选择shard key时，要根据业务的需求及『范围分片』和『Hash分片』2种方式的优缺点合理选择，要根据字段的实际原因对数据进行分片，否则会产生过大的Chunk
Mongos
Mongos作为Sharded cluster的访问入口，所有的请求都由mongos来路由、分发、合并，这些动作对客户端driver透明，用户连接mongos就像连接mongod一样使用。
-
查询请求
查询请求不包含shard key，则必须将查询分发到所有的shard，然后合并查询结果返回给客户端
查询请求包含shard key，则直接根据shard key计算出需要查询的chunk，向对应的shard发送查询请求 -
写请求
写操作必须包含shard key，mongos根据shard key算出文档应该存储到哪个chunk，然后将写请求发送到chunk所在的shard。 -
更新/删除请求
更新、删除请求的查询条件必须包含shard key或者_id，如果是包含shard key，则直接路由到指定的chunk，如果只包含_id，则需将请求发送至所有的shard。 -
其他命令请求
Config Server
config database
Config server存储Sharded cluster的所有元数据，所有的元数据都存储在config数据库
Config Server可部署为一个独立的复制集，极大的方便了Sharded cluster的运维管理。
config.shards
config.shards集合存储各个Shard的信息，可通过addShard、removeShard命令来动态的从Sharded cluster里增加或移除shard
config.databases
config.databases集合存储所有数据库的信息，包括DB是否开启分片，primary shard信息，对于数据库内没有开启分片的集合，所有的数据都会存储在数据库的primary shard上。
config.colletions
数据分片是针对集合维度的，某个数据库开启分片功能后，如果需要让其中的集合分片存储，则需调用shardCollection命令来针对集合开启分片。
config.chunks
集合分片开启后，默认会创建一个新的chunk，shard key取值[minKey, maxKey]内的文档（即所有的文档）都会存储到这个chunk。当使用Hash分片策略时，也可以预先创建多个chunk，以减少chunk的迁移。
config.settings
config.settings集合里主要存储sharded cluster的配置信息，比如chunk size，是否开启balancer等
其他集合
config.tags主要存储sharding cluster标签（tag）相关的你洗
config.changelog主要存储sharding cluster里的所有变更操作，比如balancer迁移chunk的动作就会记录到changelog里
config.mongos存储当前集群所有mongos的信息
config.locks存储锁相关的信息，对某个集合进行操作时，比如moveChunk，需要先获取锁，避免多个mongos同时迁移同一个集合的chunk。
至此：分片集群架构及原理介绍完毕。
