MongoDB分布式集群（一）

MongoDB分布式集群

集群方式有三种：Master-Slaver（主从）、Replica Set（副本集）、Sharding（分片）三种方式。

关于MongoDB集群：

三种模式各有优劣，适用于不同的场合，属Replica set应用最为广泛，主从模式现在用的较少，sharding模式最为完备，但配置维护较为复杂。

MongoDB副本集模式简述：

保证数据在生产部署时的冗余和可靠性，通过在不同的机器上保存副本来保证数据的不会因为单点损坏而丢失。能够随时应对数据丢失、机器损坏带来的风险。
换一句话来说，还能提高读取能力，用户的读取服务器和写入服务器在不同的地方，而且，由不同的服务器为不同的用户提供服务，提高整个系统的负载。

副本集是由1个主节点（Primary）、至少一个副本节点（Secondary）和最多一个仲裁节点（Arbiter）组成，仲裁节点可以不存在。
Primary：接收所有的写请求，然后把修改同步到所有Secondary。当Primary挂掉后，其他Secondary或者Arbiter节点会重新选举出来一个主节点。
Secondary：与主节点保持同样的数据集。
Arbiter：不保有数据，在选举中，不参与选主，只进行选主投票。

MongoDB分片模式简述：

分片是把大型数据集进行分区成更小的可管理的片，这些数据片分散到不同的mongoDB节点，这些节点组成了分片集群。 在生产环境中，通常是分片和副本集这两种技术结合使用。

分片是由分片服务器（Shard）、配置服务器（Config Server）和前端路由（Routers）组成。
Shard：用于存储实际的数据块。实际生产环境中一个shard server 角色可以由几台服务器组成一个Peplica Set（副本集）承担，防止主机单点故障。
Config Server：主要是记录shard的配置信息（元信息metadata），如数据存储目录，日志目录，端口号，是否开启了journal等信息，其中包括chunk（分片节点上的保存单位，每个chunk有大小限制，默认64MB，达到之后会分成2个chunk）信息。为了保证config服务器的可用性，也做了副本集处理（mongodb3.0版本以上要求副本集处理）。注意，一旦配置服务器无法使用，则整个集群就不能使用了，一般是独立的三台服务器实现冗余备份，这三台可能每一台是独立的副本集架构。
Routers：负责数据的分片写入。客户端由此接入，且让整个群集看上去像单一数据库，前端应用可以透明使用。应用程序通过驱动程序直接连接router，router启动时从配置服务器副本集中读取shared信息，然后将数据实际写入或读取（路由）到具体的shard中。
MongoDB分片优势：
–分片为应对高吞吐量与大数据量提供了方法：
1. 使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，群集可以提高自己的存储容量。比如，当插入一条数据时，应用只需要访问存储这条数据的分片。
2. 使用分片减少了每个分片村存储的数据。
–分片的优势在于提供类似线性增长的架构，提高数据可用性，提高大型数据库查询服务器的性能。当MongoDB单点数据库服务器存储成为瓶颈、单点数据库服务器的性能成为瓶颈或需要部署大型应用以充分利用内存时，可以使用分片技术。

MongoDB分布式集群架构

主机IP	路由服务器(Routers)	路由服务器(Routers)	Shard1	Shard2
192.168.2.138	28017	28018	27018	27019
192.168.2.113	28017	28018	27018	27019
192.168.2.112	28017	28018	27018	27019