MongoDB自学日记3——架构及HA

　　在对mongoDB的操作有了一定基础后，终于可以扯扯HA和架构这两个高大上的概念了。在这之前当然还得弄清楚mongoDB的Key feature：Sharding。

1. Sharding

　　Shard从逻辑上来说就是整个数据的一个子集，从物理来说就是管理这一子集的服务器。一个分片可以包含多台服务器。若一个分片包含多台服务器则每台服务器都有一份完全相同的数据子集副本（Replica set）。

　　分片是MongoDB强调的一个Feature。分片的目的就在于完成自动化集群运维。mongoDB cluster需要三种角色，Sharding server /Config Server /Route。

2. HA

　　HA是个大话题，从一个简单系统的部署为点开始谈谈吧。

　　如图所示，架构上一个mongoDB集群需要上述三种角色，这三种角色分别对应三个进程：mongos，shardsvr mongod和config mongod。



figure1

Step1：启动shard server实例1与实例2

>mongod --shardsvr --port 20000 --dbpath=/data/shared/s0 --fork --logpath=/data/shard/log/s0.log --directoryperdb >mongod --shardsvr --port 20001 --dbpath=/data/shared/s1 --fork --logpath=/data/shard/log/s1.log --directoryperdb

Step2：启动Config Server实例

>mongod --configsvr --port 30000 --dbpath=/data/shared/config --fork --logpath=/data/shard/log/config.log --directoryperdb

Step3：启动Route Server实例

>mongos --port 40000 --configdb localhost:30000 --fork --logpath=/data/shared/log/route.log --chunkSize 64

　　

　　其中chunkSize指定chunk大小，单位为MB，默认大小为200MB。

　　MongoDB auto-sharding解决了海量存储和动态扩容问题，然而以上离真正的生产环境HA方案还差的远。下面更进一步，搭建Replica Sets + Sharding解决方案，设计案例。

Case1：

Shard：使用Replica Sets，确保每个数据节点都具有备份、自动容错转移、自动恢复能力。

Config Server：使用3个配置服务器，确保元数据完整性，存放key的对应关系。

Route Server：使用方法3个路由进程，实现负载均衡，提高客户端的接入性能及并发度。

搭建上述集群完毕后，可以加入memcached服务器，将高访问量的数据缓存在内存中，避免高频度的磁盘I/O，从而进一步提升性能。

表1 小型使用案例举例

Host	IP	服务及端口分配
Server A	192.168.3.231	Mongod shard1_1: 27017 Mongod shard2_1: 27018 Mongod config1: 20000 Mongos1: 30000
Server B	192.168.3.232	Mongod shard1_2: 27017 Mongod shard2_2: 27018 Mongod config2: 20000 Mongos2: 30000
Server C	192.168.3.233	Mongod shard1_3: 27017 Mongod shard2_3: 27018 Mongod config3: 20000 Mongos3: 30000

　　当然实际使用环境中的集群系统肯定更复杂，HA不是一个简单的话题，更包括容灾备份等问题，本人也没有什么实践经验，因此也只能说说一些理论的东西，希望与大家共同交流学习。

　　按照惯例，要图文并茂，今天画的是坂田银时，相信园子里喜欢银魂的人不在少数，之前看到许多朋友都是银魂的头像。在孤独地编程、写作时，《银魂》似乎支撑了很多人，毒舌吐槽的背后是一个个简单而又平凡的人生真谛，温暖人心。有兴趣的可以看看新世相的这篇文章《阁下想要保护的东西已经是一片虚无》。



　　

　　全栈路上，没有归途。