【图解MongoDB集群部署原理（3）】MongoDB的集群部署方案中有三类角色：实际数据存储结点、配置文件存储结点和路由接入结点。
连接的客户端直接与路由结点相连，从配置结点上查询数据，根据查询结果到实际的存储结点上查询和存储数据。MongoDB的部署方案有单机部署、复本集（主备）部署、分片部署、复本集与分片混合部署。
混合的部署方式如图：
文章图片
混合部署方式下向MongoDB写数据的流程如图：
文章图片
混合部署方式下读MongoDB里的数据流程如图：
文章图片
对于副本集，又有主和从两种角色，写数据和读数据也是不同，写数据的过程是只写到主结点中，由主结点以异步的方式同步到从结点中：
文章图片
而读数据则只要从任一结点中读取，具体到哪个结点读取是可以指定的：
文章图片
对于MongoDB的分片，假设我们以某一索引键（ID）为片键，ID的区间[0,50]，划分成5个chunk，分别存储到3个片服务器中，如图所示：
文章图片
假如数据量很大，需要增加片服务器时可以只要移动chunk来均分数据即可。
配置结点：
存储配置文件的服务器其实存储的是片键与chunk以及chunk与server的映射关系，用上面的数据表示的配置结点存储的数据模型如下表：
Map1
| Key range | chunk |
|---|---|
| [0,10) | chunk1 |
| [10,20) | chunk2 |
| [20,30) | chunk3 |
| [30,40) | chunk4 |
| [40,50) | chunk5 |
| chunk | shard |
|---|---|
| chunk1 | shard1 |
| chunk2 | shard1 |
| chunk3 | shard2 |
| chunk4 | shard2 |
| chunk5 | shard3 |
路由角色的结点在分片的情况下起到负载均衡的作用。
关注微信公众号『 Tom弹架构 』回复“MongoDB”可获取配套资料。
本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号『 Tom弹架构 』可获取更多技术干货！原创不易，坚持很酷，都看到这里了，小伙伴记得点赞、收藏、在看，一键三连加关注！如果你觉得内容太干，可以分享转发给朋友滋润滋润！
