MongoDB集群以及高可用性

1：主从模式

主节点挂掉了后从节点可以接替主机继续服务。所以这种模式比单节点的可用性要好很多。

主节点提供读写操作、从节点只提供读操作。

可以采取只从多个从节点读、一个主节点写的策略，减少主节点的读写压力。

2：副本集

MongoDB官方已经不建议使用主从模式，推荐使用副本集。

主从模式如果主节点挂了，只能手动选择一个从节点作为主节点重启：

客户端连接到整个副本集，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一但主节点挂掉，副本节点就会选举一个新的主服务器，这一切对于应用服务器不需要关心。

主从模式，如果只从主节点上读写，主节点可能读写压力过大：

读写分离，只在主节点写，副本集其他节点读。

primary:默认参数，只从主节点上进行读取操作；

primaryPreferred:大部分从主节点上读取数据,只有主节点不可用时从secondary节点读取数据。

secondary:只从secondary节点上进行读取操作，存在的问题是secondary节点的数据会比primary节点数据“旧”。

secondaryPreferred:优先从secondary节点进行读取操作，secondary节点不可用时从主节点读取数据；

nearest:不管是主节点、secondary节点，从网络延迟最低的节点上读取数据。

主从模式，所有的从节点都从主节点复制全部的信息，主节点的复制压力大：

副本集中节点类型：

主节点：

副本节点：

仲裁节点：仲裁节点不存储数据，只是负责故障转移的群体投票，这样就少了数据复制的压力

Secondary-Only:不能成为primary节点，只能作为secondary副本节点，防止一些性能不高的节点成为主节点。

Hidden:这类节点是不能够被客户端制定IP引用，也不能被设置为主节点，但是可以投票，一般用于备份数据。

Delayed：可以指定一个时间延迟从primary节点同步数据。主要用于备份数据，如果实时同步，误删除数据马上同步到从节点，恢复又恢复不了。

Non-Voting：没有选举权的secondary节点，纯粹的备份数据节点。

主节点如何选择的？

3：分片

副本集合存在问题：

从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？

数据压力大到机器支撑不了的时候能否做到自动扩展？

分片的组件：

mongos，数据库集群请求的入口，所有的请求都通过mongos进行协调，不需要在应用程序添加一个路由选择器，mongos自己就是一个请求分发中心，它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口，防止其中一个挂掉所有的mongodb请求都没有办法操作。 

config server，顾名思义为配置服务器，存储所有数据库元信息（路由、分片）的配置。mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息，以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器，因为它存储了分片路由的元数据，这个可不能丢失！就算挂掉其中一台，只要还有存货， mongodb集群就不会挂掉。

shard:

replica set: