mongodb分片集群机制和原理

引文

本篇对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%以上，则开始考虑扩展。

• 扩展需要新的资源，申请新资源需要时间
• 扩展后数据需要均衡，均衡需要时间。应保证新数据入库速度慢于均衡速度
• 均衡需要资源，如果资源即将或已经耗尽，均衡也是会很低效的

结言：

分片集群可以有效解决性能瓶颈及系统扩容问题！

分片额外消耗较多，管理复杂，能不分片尽量不要分片 ！