MongoDB副本集和分片解析

Replica Set 副本集模式

Replica Set 模式角色
Replica Set 是 MongoDB 的实例集合，包含三类节点角色：

• Primary （主节点）

只有 Primary 是可读可写的，Primary接受的所有的写请求，然后把数据同步到所有的 Secondary。一个 Replica Set 只有一个 Primary 节点，当 Primary 挂掉后，其他 Secondary 或 Arbiter 节点会重新选举出来一个 Primary 节点，这样就又可以提供服务了。
读请求默认是发到 Primary 节点处理，如果需要转发到 Secondary 需要客户端修改一下配置（注：是客户端配置，决策权在客户端）。
这里和 master-slave 模式的最大区别在于，Primary 角色是通过整个集群共同选举出来的，人人都可能成为 Primary，人人最开始只是 Secondary，而这个选举过程完全自动，不需要人为参与，从而解决单点故障问题。

• Secondary （副本节点）

数据副本节点，当主节点挂掉的时候，参与选主。
Secondary和 master-slave 模式的 slave角色的区别：
Secondary 相互有心跳，Secondary 可以作为数据源，Replica 可以是一种链式的复制模式。

• Arbiter （仲裁者）

不存数据，不会被选为主，只进行选主投票。使用 Arbiter 可以减轻在减少数据的冗余备份，又能提供高可用的能力。
如图：

MongoDB 的 Replica Set 副本集模式主要有以下几个特点：
1. 数据多副本，在故障的时候，可以使用备份的副本恢复服务。注：这里是故障自动恢复；
2. 读写分离，读的请求分流到副本上，减轻主的读压力；
3. 节点之间互相有心跳，可以感知集群的整体状态；

Replica Set 副本集模式的优缺点：
可用性大大增强，因为故障时自动恢复，主节点故障，立马就能选出一个新的主节点。但是有一点需要注意：每两个节点之间互有心跳，这种模式会导致节点的心跳几何倍数增大，单个 Replica Set 集群规模不能太大，一般来讲最大不要超过50个节点。
参与投票节点数要是奇数，这个非常重要。因为偶数的话会导致脑裂，也就是投票数对等的情况下，无法选出 Primay。
举个例子，如果有3张票，那么一定是2：1，有一个一定会是多数票，如果是4张票，那么很有可能是2：2，那么就会有平票现象。

Sharding 模式

按道理 Replica Set 模式已经非常好的解决了可用性问题，为什么还会往后演进呢，因为在当今大数据时代，有一个必须要考虑的问题：数据量
用户的数据量是永远都在增加的，理论上是没有上限的，但 Replica Set 确实有上限的。
举个例子，假设说你的单机有 10TiB 的的空间，内存是 500GiB，网卡是 40G,这个就是单机的物理极限。当数据量超过 10TiB，这个 Replica Set 就无法提供服务了。而且单机的容量和性能一定是有物理极限的（比如说你的磁盘槽位可能最多就60盘）。

解决方案就是：利用分布式技术。
解决性能和容量瓶颈一般来说优化有两个方向：
1.纵向优化：
纵向优化是传统企业最常见的思路，持续不断地加大单个磁盘和机器的容量和性能。CPU 主频不断地提升，核数也不断的增加，磁盘容量从 128GiB 变成当今普遍的 12TiB，内存容量从以前的 M 级别变成现在的上百 G。带宽从以前的百兆网卡变成现在普遍的万兆网卡，但这些终究追不上互联网数据规模的增加量级。
2.横向优化：
横向优化通俗来讲就是加节点，横向扩容来解决问题。业务上要划分系统数据集，并在多台服务器上处理，做到容量和能力跟机器数量成正比。单台计算机的整体速度或容量可能不高，但是每台计算机只能处理全部工作量的一部分，因此与单台高速大容量服务器相比，可能提供更高的效率。

MongoDB 的 Sharding 模式就是 MongoDB 横向扩容的一个架构实现。
Sharding 模式角色：

Sharding 模式下按照层次划分可以分为3个大模块：
1.代理层：mongos
2.配置中心：副本集群（mongod）
3.数据层：shard 集群
如下图：

代理层：（Query Routers）
（路由就是 mongos 的实例，客户端直接连接 mongos，由 mongos 把读写请求路由到指定的 Shard 上去。一个 Sharding 集群，可以有一个 mongos，也可以有多个 mongos 以减轻客户端请求的压力。）
代理层的组件也就是mongos，这是个无状态的组件，纯粹就是路由功能。向上对接客户端，收到客户端写请求时，按照特定算法均衡散列到某一个 Shard 集群，然后数据就写到 Shard 集群了。收到读请求时，定位找到这个要读的对象在哪个 Shard 上，就把请求转发到这个 Shard 上，就能读到数据了。

数据层：（Shards）
（可以是一个单独的 mongod 实例，也可以是一个副本集。生产环境下 Shard 一般是一个副本集，防止该数据片的单点故障。所有 Shard 中有一个 PrimaryShard，里面包含未进行划分的数据集合）
数据层就是存储数据的地方。其实数据层就是由一个个 Replica Set（副本集）集群组成。在前面说过，单个 Replica Set 是有极限的，怎么办？那就搞多个 Replica Set，这样的一个 Replica Set 我们就叫做 Shard。理论上，Replica Set 的集群的个数是可以无限增长的。

配置中心（Config Servers）：
（保存集群的元数据（metadata），包含各个 Shard 的路由规则。）
代理层是无状态的模块，数据层的每一个 Shard 是各自独立的，那总要有一个集群统一配置管理的地方，这个地方就是配置中心。
这里面记录有多少个 Shard，每个 Shard 集群又是由哪些节点组成的。每个 Shard 里大概存储了多少数据量（以便做均衡）。
配置中心存储的就是集群拓扑，管理的配置信息。这些信息也非常重要，所以也不能单点存储。所以配置中心也是一个 Replica Set 集群，数据也是多副本的。
架构图：