mongoDB大数据——mongodb集群三种方案

第一种方案：master-slave（主从模式）：

主从复制是MongoDB最常用的复制方式，也是一个简单的数据库同步备份的集群技术，这种方式很灵活。可用于备份、故障恢复、读扩展等。

最基本的设置方式就是建立一个主节点和一个或多个从节点，每个从节点要知道主节点的地址。采用双机备份后主节点挂掉了后从节点可以接替主机继续服务。所以这种模式比单节点的高可用性要好很多。

但是当主节点挂掉后，不能自动切换到从节点，mongodb官方也放弃了此种方式配置的集群。如果需要自行百度了解安装吧。

---

第二种方案：Replica set（副本集模式）：

副本集是一种在多台机器同步数据的进程，副本集体提供了数据冗余，扩展了数据可用性。副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多个副本存在，并且解决了"主节点挂掉后，整个集群内会自动切换"的问题。

副本集比传统的Master-Slave主从复制有改进的地方就是它可以进行故障的自动转移,如果我们停掉复制集中的一个成员,那么剩余成员会再自动选举一个成员,作为主库。

副本集使用的是 n 个 mongod 节点，构建具备自动的容错功能(auto-failover)、自动恢复的(auto-recovery)的高可用方案。使用 副本集来实现读写分离。通过在连接时指定或者在主库指定slaveOk,由Secondary 来分担读的压力,Primary 只承担写操作。对于 Replica Set 中的 secondary 节点默认是不可读的。

副本集需要注意的地方：

A、最小构成是：primary（主节点），secondary（副本节点），arbiter（仲裁节点），一般部署是：primary（主节点），2 secondary（副本节点）。

B、成员数应该为奇数，如果为偶数的情况下添加arbiter（仲裁节点），arbiter（仲裁节点）不保存数据，只投票。复制集内投票成员（后续介绍）数量为N，则大多数为 N/2 + 1，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。

投票成员数	大多数	容忍失效数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

C、最大50 members（副本集节点成员），但是只能有 7 voting members（投票节点），其他是non-voting members（非投票节点）。

副本集正常工作图，如下所示：

副本集主节点宕机后工作图，如下所述：

---

第三种方案：Sharding（分片模式）：

分片为应对高吞吐量与大数据量提供了方法。使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，集群可以提高自己的存储容量和吞吐量。

MongoDB自带了一个叫做mongos的专有路由进程。mongos就是掌握统一路口的路由器，其会将客户端发来的请求准确无误的路由到集群中的一个或者一组服务器上，同时会把接收到的响应拼装起来发回到客户端。

MongoDB通过多种途径来确保集群的可用性和可靠性。将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每分数据都有相应的备份，这样就可以确保有服务器换掉时，其他的从库可以立即接替坏掉的部分继续工作。

当系统需要更多的空间和资源的时候，MongoDB使我们可以按需方便的通过增加集群节点，低成本、高质量的实现扩充系统容量。

组件	说明
Config Server	存储集群所有节点、分片数据路由信息。默认需要配置3个Config Server节点。
Mongos	提供对外应用访问，所有操作均通过mongos执行。一般有多个mongos节点。数据迁移和数据自动平衡。
Mongod	存储应用数据记录。一般有多个Mongod节点，达到数据分片目的。

分片集群架构示意图，如下所示：

分片集群实际服务器部署实例图，如下所示：