NOSQL，MongoDB分布式集群架构

MongoDB分布式集群架构
看到这里相信你已经掌握了 MongoDB 的大部分基本知识，现在在单机环境下操作 MongoDB 已经不存在问题，但是单机环境只适合学习和开发测试，在实际的生产环境中，MongoDB 基本是以集群的方式工作的。集群的工作方式能够保证在生产遇到故障时及时恢复，保障应用程序正常地运行和数据的安全。

重点介绍 MongoDB 的集群工作方式，以及在集群工作方式下，MongoDB 是如何使用分片和复制的机制来完成对数据的管理和恢复的。

MongoDB 有三种集群部署模式，分别为主从复制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。

Master-Slaver： 是一种主从副本的模式，目前已经不推荐使用。
Replica Set ：模式取代了 Master-Slaver 模式，是一种互为主从的关系。Replica Set 将数据复制多份保存，不同服务器保存同一份数据，在出现故障时自动切换，实现故障转移，在实际生产中非常实用。
Sharding ：模式适合处理大量数据，它将数据分开存储，不同服务器保存不同的数据，所有服务器数据的总和即为整个数据集。
Sharding 模式追求的是高性能，而且是三种集群中最复杂的。
在实际生产环境中，通常将 Replica Set 和 Sharding 两种技术结合使用。

主从复制
虽然 MongoDB 官方建议用副本集替代主从复制，但还是让大家了解 MongoDB 的复制机制。

主从复制是 MongoDB 中最简单的数据库同步备份的集群技术，其基本的设置方式是建立一个主节点（Primary）和一个或多个从节点（Secondary）

种方式比单节点的可用性好很多，可用于备份、故障恢复、读扩展等。集群中的主从节点均运行 MongoDB 实例，完成数据的存储、查询与修改操作。

主从复制模式的集群中只能有一个主节点，主节点提供所有的增、删、查、改服务，从节点不提供任何服务，但是可以通过设置使从节点提供查询服务，这样可以减少主节点的压力。

另外，每个从节点要知道主节点的地址，主节点记录在其上的所有操作，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。

在主从复制的集群中，当主节点出现故障时，只能人工介入，指定新的主节点，从节点不会自动升级为主节点。同时，在这段时间内，该集群架构只能处于只读状态。

此集群拥有一个主节点和多个从节点，这一点与主从复制模式类似，且主从节点所负责的工作也类似，但是副本集与主从复制的区别在于：当集群中主节点发生故障时，副本集可以自动投票，选举出新的主节点，并引导其余的从节点连接新的主节点，而且这个过程对应用是透明的。

可以说，MongoDB 的副本集是自带故障转移功能的主从复制。

MongoDB 副本集使用的是 N 个 mongod 节点构建的具备自动容错功能、自动恢复功能的高可用方案。在副本集中，任何节点都可作为主节点，但为了维持数据一致性，只能有一个主节点。

主节点负责数据的写入和更新，并在更新数据的同时，将操作信息写入名为 oplog 的日志文件当中。主节点还负责指定其他节点为从节点，并设置从节点数据的可读性，从而让从节点来分担集群读取数据的压力。

另外，从节点会定时轮询读取 oplog 日志，根据日志内容同步更新自身的数据，保持与主节点一致。

在一些场景中，用户还可以使用副本集来扩展读性能，客户端有能力发送读写操作给不同的服务器，也可以在不同的数据中心获取不同的副本来扩展分布式应用的能力。

在副本集中还有一个额外的仲裁节点（不需要使用专用的硬件设备），负责在主节点发生故障时，参与选举新节点作为主节点。

副本集中的各节点会通过心跳信息来检测各自的健康状况，当主节点出现故障时，多个从节点会触发一次新的选举操作，并选举其中一个作为新的主节点。为了保证选举票数不同，副本集的节点数保持为奇数。

分片
副本集可以解决主节点发生故障导致数据丢失或不可用的问题，但遇到需要存储海量数据的情况时，副本集机制就束手无策了。副本集中的一台机器可能不足以存储数据，或者说集群不足以提供可接受的读写吞吐量。这就需要用到 MongoDB 的分片（Sharding）技术，这也是 MongoDB 的另外一种集群部署模式。