一、角色说明
要构建一个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：建议框架图
转自：http://blog.csdn.net/sxb0841901116/article/details/40839149