可复制集
mongoDB可复制集本质上是对主从复制模型的增强。在主从复制的基础上增加了自动化切主、平滑迁移的功能。
最小的可复制集群至少有3个节点，主、从节点和一个裁判节点。裁判节点不包含数据，只在主节点down后进行重新选主操作。
构建可复制集群
构建一个包含3个节点的集群。一个主节点，一个从节点，一个裁判节点。
mongod --replSet myrepl --dbpath /data/data1 --port 27017
mongod --replSet myrepl --dbpath /data/data2 --port 27018
mongod --replSet myrepl --dbpath /data/data3 --port 27019
在有数据的一个节点客户端（若都没数据则随便选一个）执行以下命令初始化集群。这里在27019节点操作。
rs.initiate(),在该节点初始化集群，此时集群只有一个这一个节点。- 使用
rs.add("host:port")添加其他节点。如rs.add('localhost:27018')添加从节点，使用rs.add("localhost:27017"，true)添加裁判节点。
裁判节点可理解为轻量级的节点，不参与复制但参加主节点的选举。
复制操作时异步的。
一般来说，拥有最新optlog(或更高优先级的)节点可以称为主节点。
复制原理
复制操作依靠两个基础机制：（oplog）操作日志和(heartbeat)心跳检测完成。操作日志记录着所有的写操作，提供数据复制的依据，而心跳检测则用于触发故障转移。
oplog记录着所有写操作，为数据复制提供了基础（可以把它当做操作日志）。一般主节点完成写操作后会将写数据记录到oplog中。从节点再到主节点复制oplog,将新的更改应用到从节点（根据各自的时间戳应用）。
若集群只剩下主节点，则主节点会降级成从节点。
设置复制集群参数：
- votes,默认每个节点一票，可修改，但一般不会
- 可设置节点优先级(priority),值为0-100，便于选举时成为主节点，若为0，则不会称为主节点，通常用于灾难备份节点，另外对于灾难备份节点，可使用延迟复制（slaveDelay）功能。
分片集群
模型架构
分片集群由若干分片、mongos(路由器)及配置服务器组成。其中，
- 一个分片本质上就是一个可复制集群，
- mongos负责消息路由，接收客户端请求。它本身不储存集群细腻系，没有持久化，所有配置信息向配置服务器请求。
- 配置服务器储存集群数据，数据库和集合的数据起始位置以及迁移记录。
对于分片集群而言，分片键的选取很重要。一般不要选择分布性查的字段，这样会导致数据都集中在一个分片上，无法利用分片集群的优势，但也不要选择完全随机的字段，这样会导致数据分布完全没有逻辑，无法利用局部性原理。查询会很费力。最好使用粗粒度+细粒度的复合分片键。如基于用户id和文档主键的分片键（userId+docId）。
| 方式 | 说明 | 特点 |
|---|---|---|
| 单机模式 | 一个mongod节点 | 无从节点，无高可用 |
| 主从 | 一个主节点和多个从节点组成 | 不能自动容灾，主节点down掉需人工重启维护，维护性查，不能高可用，目前已经不再应用 |
| 可复制集群 | 结构和主从一致，一个主节点点配置若干从节点或裁判节点 | 对主从结构的完善，当主节点挂掉后可自动选主节点，期间过程对用户透明，实现了高可用性 |
| 分片集群 | 有分片节点，路由节点和配置服务器集群组成，其中每个分片节点即是一个可复制集群 | 在可复制集群基础上添加了分片概念，可应对数据量过大的情况，结构也相对复杂。 |