为什么要用sharing？
Sharding: 优点
越来越大的数据集及不断提升吞吐量的应用程序对单台mongodb服务器来讲是一个挑战————大量的查询很快即能耗尽CPU的计算能力，而较大的数据集存储需求也有可能很快超出单节点的存储能力。最终，工作集的大多超出了系统的RAM并给I/O带去巨大压力。数据库管理系统界解决此类问题通常有两类方案：向上扩展和水平扩展。
sharding即是水平扩展的一种解决方案。它通过将数据集分布于多个也称作分片(shard)的节点上来降低单节点的访问压力。每个分片都是一个独立的数据库，所有的分片组合起来构成一个逻辑上的完整意义的数据库。因此，分片机制降低了每个分片的数据操作量及需要存储的数据量。
mongodb的每个分片默认64M
mongodb的复制原理：
replica Set复制原理：
mongod复制原理同mysql
主节点将所有操作记录在本地的一个成为oplog的日志文件中，从节点定期去主节点复制这些写操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。
replica Set
（图片来源于互联网）
replica Set使用的是n个mongod节点，构建具备自动的容错功能(auto-failover),自动恢复的(auto-recovery)的高可用方案。
使用Replica Set来实现读写分离。通过在连接时指定或者在主库指定slaveOk，由Secondary来分担读的压力，Primary只承担写操作。
对于Replica Set中的secondary 节点默认是不可读的。
sharding
（图片来源于互联网）
mongodb的sharding功能是指mongodb通过mongos自动建立一个水平扩展的数据库集群系统，将数据库分表存储在sharding的各个节点上。
通过把Sharding和Replica Sets相结合，可以搭建一个分布式的，高可用性，自动水平扩展的集群。
要构建MongoDB Sharding Cluster，需要三种角色：
Shard Server: mongod 实例， 使用 Replica Sets，确保每个数据节点都具有备份、自动容错转移、自动恢复能力。用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组个一个relica set承担，防止主机单点故障
Config Server: mongod 实例，使用 3 个配置服务器，确保元数据完整性(two-phase commit)。存储了整个 Cluster Metadata，其中包括 chunk 信息。
Route Server: mongos 实例，配合 LVS，实现负载平衡，提高接入性能(high performance)。前端路由，客户端由此接入，且让整个集群看上去像单一数据库，前端应用可以透明使用。
oplog介绍
主节点的操作记录称为oplog(operation log)，oplog存储在local数据库中(local数据库不会被复制，用来存放复制状态信息的)。
oplog中的每个文档代表着主节点上执行的操作。oplog只作为从节点与主节点保持数据同步的机制。
默认情况下，64位的实例将使用oplog 5%的可用空间，这个空间将在local数据库中分配，并在服务器启动时预先分配。切启动之后设置不生效
如果从节点落后主节点很远了，oplog日志从节点还没执行完，oplog可能已经轮滚一圈了，那么从节点将会追赶不上主节点了，复制将会停止。从节点需要重新做完整的同步，可以用{resync:1}命令来手动执行重新同步或在启动从节点时指定--autoresync选项让其自动重新同步。重新同步的代价昂贵，应尽量避免，避免的方法就是配置足够大的oplog。
sharding特性：
主要是把数据和元数据进行分离
config server存储元数据
sharding存储数据.
mongos代理
读操作：客户端请求进入mongos之后需要去configserver上去获取数据具体在哪个分片上，然后在和相应的节点进行通信然后再把数据在本地整合起来返回给客户端
写操作：对于分片集群分片集合，mongos将应用程序的写操作直接特定到指定的分片。mongos从config server使用集群元数据将写操作路由到适当的分片上。基于片键将数据分区，然后，MongoDB将这些块分片到分片上， 片键决定块分片的分布情况。这可能会影响集群写操作的性能。
