引文
本篇对mongodb分片集群的机制和原理进行讲解，但是如果不是特殊的业务场景需求，不建议采用分片集群的部署方式，因为会造成很多资源的冗余和浪费，建议综合考虑成本再做架构设计。
1、mongodb常见的部署方式
单机部署(部署占比20%左右)
主要用于开发和测试，其他场景很少见单机部署容易造成数据的丢失和环境的不稳定性。
副本集 (部署占比70%左右)
采用一主多从副本集的部署方式，可以满足大部分的业务场景，既可以保证服务的稳定性，还可以实现读写分离的策略，提高写入和读取的性能问题。
分片集群：横向扩展（整体占比10%左右）
如果不是数据量特比大的特殊场景，不建议使用该部署方式，会多出来很多资源的冗余，需要又路由机器和配置服务的资源部署，而且还要考虑合理的分片片键的设计。
2、分片集群的使用场景
MongoDB数据容量日益增大，访问性能日渐降低 统上线异常火爆，需要支撑更多的并发用户 MongoDB已有10TB 数据，发生故障，恢复时间漫长 系统的访问用户针对全球（需要做地理分布数据）
3、分片集群的数据分布写入方式
mongodb的数据按照从小到大的概念分别是片键、文档、块、片和分片集群
片键 shard key： 文档中的一个字段
文档 doc ：包含 shard key 的一行数据
块 Chunk ：包含 n 个文档
分片 Shard：包含 n 个 chunk
集群 Cluster：包含 n 个分片
基于范围的数据分布
按照数据的范围进行分片划分（如下图，min~-75，-75 ~ 25 ，25 ~175这些都是范围）
优点：采用范围查询性能好，可以优化业务的读操作。
缺点：数据分布不均匀（容易有热点问题），比如如果是以主键划分范围，而主键是自增ID的话，那么大量的写入操作的数据极容易落到一个分片，导致热点问题。
基于哈希
按照数据的hash值来进行分片
优点：数据分布均匀，针对写入操作是比较优化的，适用：日志、物联网等高并发场景。
缺点：范围查询效率低
自定义Zone
根据节点定义一个Zone,比如国际区号：1开头的读写美国的服务器，86开头的读写中国的服务器，方便完成国际化的全球项目的部署。
4、完整的分片集群部署
分片集群主要是由路由器、配置中心和副本集群组成，具体的结构图如下：
路由节点（mongos）
提供集群单一入口（可以有多个，理论上只需要使用一个，建议至少2个达到高可用）
功能：转发应用端请求，选择合适数据节点进行读写，合并多个数据节点的返回
配置（目录）节点
搭建：就是普通的复制集架构，一般1主2从提供高可用。
提供集群元数据存储，分片数据分布的映射（哪些数据放在哪个分片集群）
配置节点中比较重要的就是Shared这张表，里面存储分片中数据的范围。
（mongos在启动的时候会把配置节点的数据加载到自己的内存当中，方便快的进行数据的比对，完成数据的分发处理）
数据节点（mongod）
以复制集为单位（避免单点故障）
分片之间数据不重复
横向扩展
最大1024分片
所有分片在一起才可完整工作
5、分片集群的特点
应用全透明，无特殊处理数据自动均衡动态扩容，无须下线基于三种分片方式
6、分片集群的资源问题
mongos 与 config 通常消耗很少的资源，可以选择低规格虚拟机；
资源的重点在于 shard 服务器：
需要足以容纳热数据索引的内存；正确创建索引后 CPU 通常不会成为瓶颈，除非涉及非常多的计算；磁盘尽量选用 SSD；
即使项目初期已经具备了足够的资源，仍然需要考虑在合适的时候扩展。建议监控各项资源使用情况，无论哪一项达到60%以上，则开始考虑扩展。
扩展需要新的资源，申请新资源需要时间扩展后数据需要均衡，均衡需要时间。应保证新数据入库速度慢于均衡速度均衡需要资源，如果资源即将或已经耗尽，均衡也是会很低效的
结言：
分片集群可以有效解决性能瓶颈及系统扩容问题！
分片额外消耗较多，管理复杂，能不分片尽量不要分片 ！
精彩文章
您阅读本篇文章共花了：
发表评论