【MongoDB】在window系统下搭建MongoDB的分片集群（一）

这篇主要讲述分片集群的主要原理

坦白说，刚看到这个分片系统（Sharding）有点蒙，感觉有点太高大上了。看美国作家Kyle Banker《MongoDB in action》没有明白。又查询资料，首先对与分片的做个说明。从其他书本上看的，说分片这是一种将海量数据水平扩展的数据库集群系统，数据分表存储在sharding的各个节点上，使用者通过简单的配置就可以很方便地够将一个分布式MongoDB集群。

一、角色说明

要构建一个MongoDB分片集群，需要三个角色：

• shard server  即存储实际数据得分片，每个shard 可以是一个Mongod实例，也可以是一组mongod实例构成得Replica Set（也就是以前博客里说明的复制集）。为了实现每个shard内部的auto-failover，MongoDB官方建议每个shard 为一组Replica set。
• Config Server  为了将一个特定的collection存储在多个shard中，需要为该collection指定一个shard key,例如｛age:1｝,shard key可以决定该条记录属于哪个chunk。（chunk将在后面做详细介绍）Config Servers就是用来存储所有shard节点的配置信息，每个chunk的shard key范围，chunk在各shard的分布情况 、该集群中所有DB和collection的sharding 配置信息
• Route Process 这个一个前端路由，客户端由此接入，然后询问config servers需要到哪个shard上查询或把保存记录，在连接相应的shard进行操作，最后讲结果返回客户端。客户端只需要将原本发给mongod的查询或更新请求原封不动地发给rounting processl.而不必关心所操作的记录存储在哪个shard上，

二、框架结构

如果用一台物理机搭建分片集群：结构图如下：

每个服务器的端口不一样

三、框架说明

由于该分片集群比较抽象，我从其他数据上看到些说明，在这里做一个补充；

A：分片是把数据库分别在多个服务器上

B：查询一个用户实际涉及两次查询，第一次访问配置数据库以获得用用户的分片位置，第二次查询直接访问包含用户数据的分片

C：主要解决说明扩容问题以及负载均衡问题

D：手动管理分片的著名框架为： Twitter的Gizzard (详见：http://mng.bz/4qvd)

E ：对现在系统的分片决定因素： 磁盘活动，系统负载以及最重要的工作集大小与可用内存的比例

F：chunk块的概念：它是位于一个分片中的一段连续的分片键范围。它们是种逻辑意义上的东西而不是物理意义上的。

G： 分片键： MongoDB的分片是基于范围的。也就是说分片的集合中每个文档都必须落在指定键的某个值范围。分片键就是让每个文档能在这些范围中找到自己的位置

H：拆分和迁移

这两个是完全不同的概念，拆分思想是当分片块数据达到一定大小时候把其分为两块。拆分后的两块都有相同数量的文档。拆分仅仅是个逻辑操作，不会影响分片集合中里文档的物理顺序。

迁移是由名为“balancer”均衡器软件进行管理的，它的任务是确保数据在各个节点中保持均匀分布。通过跟踪各分片块的数量，就能实现该功能。通常来说，当集群中拥有块最多的分片与拥有块最少的分片的块数差大于8时，均衡器就会发生一次均衡处理。

I：建议框架图