公司某产品MongoDB分布式架构总结

本篇博客的内容是对目前公司某产品在mongodb架构方面的一些研究和心得(部分来源于公司wiki及互联网)，整理一下发上来，希望对看到的人有所帮助。

一、MongoDB分布式架构相关：

1、MongoDB支持在多台机器中通过异步复制达到故障转移和实现冗余.多机器中同一时刻只有一台机器用于写操作。

2、Replica sets结构类似一个集群，其中一个节点如果出现故障，其它节点会马上将业务接过来而无需停机。担当primary角色的机器能把读操作分发给slave。

3、MongoDB的replica sets是通过一个日志来存储写操作的，这个日志叫做oplog。Oplog.rs是一个固定长度的capped collection，它存在于local数据库中，用于记录replica sets的操作日志。Oplog的大小可以通过mongod的参数—oplogSize来改变oplog的日志大小。

4、读写分离：默认的从库是不可读的，需要执行db.getMongo().setSlaveOk()，才可以查询从库。

5、复制集比传统的master-slave有改进的地方就是他可以进行故障的自动转移，如果我们停掉复制集中的任意一个成员，剩余成员会自动选举出一个成员，作为主库。这种故障处理机制，能将系统稳定性大大提高。

6、MongoDB的Replica Sets不仅提供高可用性解决方案，也提供负载均衡的解决方案。例如读压力暴增时，3台节点的环境已经不能满足需求，就需要增加节点将压力平均分配一下。

7、Sharding分片（水平扩展）

这是一种将海量数据水平扩展的数据库集群系统，数据分表存储在sharding各个节点上。

MongoDB的数据块称为chunk，每个chunk都是collection中一段连续的数据记录。通常最大空间200M，大于200M则生成新的数据块。

8、构建一个MongoDB Sharding Cluster需要三种角色：

(1)Shard Server：

每个Shard可以是一个mongod实例，也可以是一组mongod实例构成的Replica Sets。为了实现每个Shard内部的auto-failover(自动故障切换)，MongoDB建议每个Shard为一组Replica Sets。

(2)Config Server：

为了将一个特定的collection存储在多个Shard中，需要为该collection指定一个shard key，例如{age:1}。shard key决定该条记录属于哪个chunk。Config Server就是用来存储：所有Shard节点的配置信息。每个chunk的shard key范围、chunk在各shard的分布情况。该集群中所有DB和Collection的Sharding配置信息。

(3)Route Process：

前端路由，客户端由此接入。询问Config Server需要到那个Shard上查询或者保存记录。再连接相应的Shard进行操作，最后将结果返回给客户端。客户端不必关心所操作的记录在那个shard上。

二、该产品MongoDB架构：

4台服务器做分片处理，每个Shard内部做replica set复制集：

ShardA：

使用1、2、3号机器，依次设置为主、从、仲裁。

ShardB：

使用2、3、4号机器，依次设置为主、从、仲裁。

ShardC：

使用3、4、1号机器，依次设置为主、从、仲裁。

ShardD：

使用4、1、2号机器，依次设置为主、从、仲裁。

配置节点：

Mongod：部署1、2、3号机器，使用端口30001。

路由节点：

Mongos：部署全部1、2、3、4四台机器，使用端口40001。

三、补充：

1、Shard相关：

(1)Shard可以动态添加或删除，数据会被动态转移，但转移完成前仍访问的原来的shard。

(2)删除shard指令执行后，在转移完成前，停止shard节点将会导致某些数据读写失败。

(3)第一次enablesharding时，会选出default shard。

(4)其他没有被enableshard的数据库将保存在默认shard上。

(5)每个collection的shardkey只能设置一次，无法更改，除非drop这个collection再重建。

(6)版本mongodb(1.8.2)不支持shard的auth，仅支持到repli-set级别。故现在连接mongodb上的db，不需要用户名密码。

(7)sharding功能是针对collection的，而不是整个数据库DB，而且所有数据都是有序的，排序是通过：实现shard应用时指定一个或多个Key，所有的数据都将按Key排序。

2、Replica set相关：

(1)一个repli-set中，只要有一个可见的非arbiter节点存活，该set不会丢失数据。

(2)当前配置中所有非arbiter节点都是可见的，但是primary down了，在新的primary还未选举出来时马上又down一台，可能会丢数据。

(3)一个repli-set可以动态增减非Primary节点，但是也需要执行时间，执行完成后才能真正使用或停掉某节点。Arbiter节点是primay选举的投票者之一，但并不保存数据。

(4)Replica Set需要最少两个Server,配置最简单的Replica Set可以是两台服务器加一台仲裁服务器或者是三台服务器，仲裁服务器不保存任何数据，只作打破选举用，普通的服务器即可，甚至可以部署在应用服务器上。配置成功之后若PRIMARY宕机或者出现异常，Replica Set会马上切换其中的一台SECORDARY为PRIMARY，这个过程大概在30秒之内，由Replica Set自动完成。

3、Config server标准配置就是3台，down掉一台只影响resharding，不影响数据的正常读写。