MongoDB 是由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。在高负载的情况下，添加更多的节点，可以保证服务器性能。MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
MongoDB集群
MongoDB 有三种集群部署模式，分别为主从复制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。
- Master-Slaver 是一种主从副本的模式，目前已经不推荐使用。
- Replica Set 模式取代了 Master-Slaver 模式，是一种互为主从的关系。Replica Set 将数据复制多份保存，不同服务器保存同一份数据，在出现故障时自动切换，实现故障转移，在实际生产中非常实用。
- Sharding 模式适合处理大量数据，它将数据分开存储，不同服务器保存不同的数据，所有服务器数据的总和即为整个数据集。
主从复制
主从复制是 MongoDB 中最简单的数据库同步备份的集群技术，其基本的设置方式是建立一个主节点（Primary）和一个或多个从节点（Secondary），如下图所示：
主从复制模式比单节点的可用性好很多，可用于备份、故障恢复、读扩展等。这种方式只能有一个主节点，主节点提供所有的增删查改操作，而从节点不提供服务。因此，主节点的性能要求较高。但是我们可以通过设置使从节点提供查询服务，这样可以减少主节点的压力。
另外，每个从节点要知道主节点的地址，主节点记录在其上的所有操作，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。在主从复制的集群中，当主节点出现故障时，只能人工介入，指定新的主节点，从节点不会自动升级为主节点。同时，在这段时间内，该集群架构只能处于只读状态。
副本集
此集群拥有一个主节点和多个从节点，这一点与主从复制模式类似，且主从节点所负责的工作也类似，但是副本集与主从复制的区别在于：当集群中主节点发生故障时，副本集可以自动投票，选举出新的主节点，并引导其余的从节点连接新的主节点，而且这个过程对应用是透明的。
可以说，MongoDB 的副本集是自带故障转移功能的主从复制。一个副本集的成员有：
- **主节点：**主节点接受所有的写操作
- **从节点：**从节点通过复制主节点的操作来维护一个相同的数据集（不可接受写操作，但可以接受读操作）。从节点为特殊用途的配置文件提供了额外的配置项。例如，从节点可配置成无投票权 或0优先级。
- **仲裁节点：**仲裁节点没有数据集的副本，并且不能成为主节点。然而，仲裁节点可以参与主节点选举。一个仲裁节点只有
1票选举权。在某些情况下（例如有一个主节点和一个从节点，但由于成本约束无法添加另一个从节点），你可以在副本集中添加一个仲裁节点。
副本集的最小推荐配置是一个包含三个数据承载成员的三成员副本集：一个主节点和两个从节点。在某些情况下（例如你有一个主节点和一个从节点，但由于成本约束无法添加另一个从节点），你可以选择使用一个仲裁节点。仲裁节点参与选举但不持有数据（即不提供数据冗余
）。
一个副本集最多可以有50个成员，但仅能有7个可投票成员。
如上图所示，副本集的主节点是唯一一个可以接受写操作的成员。MongoDB在主节点上应用写操作，然后将这些操作记录到主节点的oplog中。从节点成员复制这个日志然后应用到它们的数据集中。副本集所有的成员都可以接受读操作。但是，默认情况下，应用程序会将其读操作定向至主节点。
一个从节点维护了主节点数据集的一个副本。为了复制数据，从节点通过异步的方式将主节点oplog应用至自己的数据集中。一个副本集可以有一个或多个从节点。
分片
副本集可以解决主节点发生故障导致数据丢失或不可用的问题，但遇到需要存储海量数据的情况时，副本集机制就束手无策了。副本集中的一台机器可能不足以存储数据，或者说集群不足以提供可接受的读写吞吐量。这就需要用到 MongoDB 的分片（Sharding）技术，这也是 MongoDB 的另外一种集群部署模式。
分片是指将数据拆分并分散存放在不同机器上的过程。有时也用分区来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以存储更多的数据，处理更大的负载。
MongoDB 支持自动分片，可以使数据库架构对应用程序不可见，简化系统管理。对应用程序而言，就如同始终在使用一个单机的 MongoDB 服务器一样。
MongoDB 的分片机制允许创建一个包含许多台机器的集群，将数据子集分散在集群中，每个分片维护着一个数据集合的子集。与副本集相比，使用集群架构可以使应用程序具有更强大的数据处理能力。
构建一个 MongoDB 的分片集群，需要三个重要的组件，分别是分片服务器（Shard Server）、配置服务器（Config Server）和路由服务器（Route Server）。
Shard Server
每个 Shard Server 都是一个 mongod 数据库实例，用于存储实际的数据块。整个数据库集合分成多个块存储在不同的 Shard Server 中。
在实际生产中，一个 Shard Server 可由几台机器组成一个副本集来承担，防止因主节点单点故障导致整个系统崩溃。
Config Server
这是独立的一个 mongod 进程，保存集群和分片的元数据，在集群启动最开始时建立，保存各个分片包含数据的信息。
Route Server
这是独立的一个 mongos 进程，Route Server 在集群中可作为路由使用，客户端由此接入，让整个集群看起来像是一个单一的数据库，提供客户端应用程序和分片集群之间的接口。
Route Server 本身不保存数据，启动时从 Config Server 加载集群信息到缓存中，并将客户端的请求路由给每个 Shard Server，在各 Shard Server 返回结果后进行聚合并返回客户端。
