Mongodb 3.4配置搭建高可用集群（1）

Mongodb的集群架构

此架构有四个组件：mongos、config server、shard、replica set。

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

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

shard：分片是指将数据库拆分，将其分散在不同的机器上的过程；一台机器的一个数据表Collection1存储了1T数据，在分给4台机器后，每个机器都是256G，分摊了集中在一台机器上的压力。在mongodb集群中只要设置好了分片规则，通过mongos操作数据库就能自动把对应数据库操作请求转发到对应的分片机器上。在生产环境中分片的片键需要好好设置，它影响到怎样把数据均匀分到多个分片机器上。将数据分散到不同的机器上，不需要功能强大的服务器就可以存储更多的数据和处理更大的负载。基本思想是将集合切成小块，这些小块分散到若干片里，每个片只负责总数据的一部分，最后通过一个均衡器来对各个分片进行均衡（数据迁移）。

replica set：上图中4个分片如果没有replica set是个不完整架构，假设其中一个分片挂掉则四分之一的数据就会丢失，所以在高可用性的分片架构还需要对于每一个分片构建replica set副本集保证分片的可靠性。生产环境通常是2个副本+1个仲裁。

Arbiter（仲裁者）：是复制集中的一个MongoDB实例，它并不保存数据。仲裁节点使用最小的资源并且不要求硬件设备，不能将Arbiter部署在同一个数据集节点中，可以部署在其他应用服务器或者监视服务器中。为了确保复制集中有奇数的投票成员（包括primary），需要添加仲裁节点作为投票，否则primary不能运行时不会自动切换primary。

应用请求mongos来操作mongodb的增删查改，配置服务器存储数据库元信息，并且和mongos做同步，数据最终存入在shared（分片）上，为了防止数据丢失同步在副本集中存储了一份，仲裁在数据存储到分片的时候决定存储到哪个节点。

Sharding的优点？

数据库管理系统界解决此类问题通常有两类方案：向上扩展和水平扩展。

Sharding即是水平扩展的一种解决方案，它通过将数据集分布于多个也称作分片（shard）的节点上来降低单节点的访问压力。每个分片都是一个独立的数据库，所有的分片组合起来构成一个逻辑上的完整意义的数据库。因此分片机制它降低了每个分片的数据操作量及需要存储的数据量。通过把Sharding和Replica Sets相结合，可以搭建一个分布式、高可用性、自动水平扩展的集群。

Shard Server：mongod实例，使用Replica Sets，确保每个数据节点都具有备份、自动容错转移、自动恢复能力。用于存储实际的数据块，实际生产环境中一个Shard Server角色可由几台机器组一个Replica Set承担，防止主机单节点故障。

Config Server：mongod实例，使用3个配置服务器，确保元数据完整性（two-phase commit）。存储了整个Cluster Metadata，其中包括chunk信息。

Route Server：mongos实例，配合LVS，实现负载均衡，提高接入性能。前端路由，客户端由此接入，且让整个集群看上去像单一数据库，前端应用可以透明使用。

MongoDB的复制原理：

Replica Set复制原理同MySQL，主节点将所有操作记录在本地的一个成为oplog的日志文件中，从节点定期去主节点复制这些写操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。