三.Mongo集群实现高可用方式详解
1.Master-slave主从模式
由两种角色构成： （1）主(Master) 可读可写，当数据有修改的时候，会将oplog同步到所有连接的salve上去。 （2）从(Slave) 只读不可写，自动从Master同步数据。 特别的，对于Mongodb来说，并不推荐使用Master-Slave架构，因为Master-Slave其中Master宕机后不能自动恢复，推荐使用Replica Set，后面会有介绍，除非Replica的节点数超过50，才需要使用Master-Slave架构，正常情况是不可能用那么多节点的。 还有一点，Master-Slave不支持链式结构，Slave只能直接连接Master。Redis的Master-Slave支持链式结构，Slave可以连接Slave，成为Slave的Slave。
2.Relica Set副本集方式 Mongodb的Replica Set即副本集方式主要有两个目的，一个是数据冗余做故障恢复使用，当发生硬件故障或者其它原因造成的宕机时，可以使用副本进行恢复。 另一个是做读写分离，读的请求分流到副本上，减轻主（Primary）的读压力。
2.1.Primary和Secondary搭建的Replica Set
2.1.1.主节点（Primary） 接收所有的写请求，然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点，当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。默认读请求也是发到Primary节点处理的，需要转发到Secondary需要客户端修改一下连接配置。
2.1.2.副本节点（Secondary） 与主节点保持同样的数据集。当主节点挂掉的时候，参与选主。
2.1.3.仲裁者（Arbiter） 不保有数据，不参与选主，只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求，Arbiter跑起来几乎没什么大的硬件资源需求，但重要的一点是，在生产环境下它和其他数据节点不要部署在同一台机器上。
注意，一个自动failover的Replica Set节点数必须为奇数，目的是选主投票的时候要有一个大多数才能进行选主决策。
2.1.4.选主过程 其中Secondary宕机，不受影响，若Primary宕机，会进行重新选主：
2.2.使用Arbiter搭建Replica Set 偶数个数据节点，加一个Arbiter构成的Replica Set方式
四.Sharding分片技术
当数据量比较大的时候，我们需要把数据分片运行在不同的机器中，以降低CPU、内存和IO的压力，Sharding就是数据库分片技术。
MongoDB分片技术类似MySQL的水平切分和垂直切分，数据库主要由两种方式做Sharding：垂直扩展和横向切分。
垂直扩展的方式就是进行集群扩展，添加更多的CPU，内存，磁盘空间等。 横向切分则是通过数据分片的方式，通过集群统一提供服务：
1.MongoDB的Sharding架构
2.MongoDB分片架构中的角色 2.1.数据分片（Shards） 用来保存数据，保证数据的高可用性和一致性。可以是一个单独的mongod实例，也可以是一个副本集。 在生产环境下Shard一般是一个Replica Set，以防止该数据片的单点故障。所有Shard中有一个PrimaryShard，里面包含未进行划分的数据集合： shards将数据分散到不同的机器上，不需要功能强大的服务器就可以存储更多的数据和处理更大的负载。基本思想就是将集合切成小块，这些块分散到若干片里，每个片只负责总数据的一部分，最后通过一个均衡器来对各个分片进行均衡（数据迁移）。
2.2.查询路由（Query Routers） 路由就是mongos的实例，客户端直接连接mongos，由mongos把读写请求路由到指定的Shard上去。 一个Sharding集群，可以有一个mongos，也可以有多mongos以减轻客户端请求的压力。 2.3.配置服务器（Config servers） 保存集群的元数据（metadata），包含各个Shard的路由规则。 mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息，以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器，因为它存储了分片路由的元数据，防止数据丢失！
