共计 5241 个字符，预计需要花费 14 分钟才能阅读完成。
本篇文章给大家分享的是有关 MongoDB 中怎么实现集群，丸趣 TV 小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着丸趣 TV 小编一起来看看吧。
基本概念
文档（document）：文档是 MongoDB 的核心概念，是数据的基本单元，类似于关系数据库中的行。在 MongoDB 中，文档表示为键值对的一个有序集。文档一般使用如下的样式来标记：
{title : hello!} {title : hello! , recommend :5} {title : hello! , recommend :5, author :{ firstname : paul , lastname : frank}}从上面的例子可以看到，文档的值有不同的数据类型，甚至可以是一个完整的内嵌文档（*** 一个示例的 author 就是一个文档）
集合（collection）：集合是一组文档的集合，相当于关系型数据库中的数据表，MongoDB 数据库不是关系型数据库，没有模式的概念。同一集合中的文档可以有不同的形式。比如：
{name : jack , age :19} {name : wangjun , age :22, sex : 1}可以存在同一个集合当中。
数据库（database）：多个文档构成集合，多个集合组成数据库。一个 MongoDB 实例可以承载多个数据库，每个数据库可以拥有 0 到多个集合。
MongoDB 的主要目标是在键值对存储方式（提供了高性能和高度伸缩性）以及传统的 RDBMS（关系性数据库）系统，集两者的优势于一身。MongoDB 适用于以下场景：
网站数据：Mongo 非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
缓存：由于性能很高，Mongo 也适合作为信息基础设施的缓存层。在系统重启之后，由 Mongo 搭建的持久化缓存可以避免下层的数据源过载。
大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。
高伸缩性的场景：Mongo 非常适合由数十或数百台服务器组成的数据库
用于对象及 JSON 数据的存储：Mongo 的 BSON 数据格式非常适合文档格式化的存储及查询。
当然 MongoDB 也有不适合的场景：
高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量事务的应用程序。
传统的商业智能应用：针对特定问题的 BI 数据库能够提供高度优化的查询方式。对于此类应用，数据仓库可能时更适合的选择（如 Hadoop 套件中的 Hive）。
需要 SQL 的问题。
集群攻略
MongoDB 在商用环境中，为了高可用性，通常都是以集群形式使用的，MongoDB 的集群环境搭建非常简单，下面就作一个介绍。
主从模式
我们在使用 MySQL 数据库时广泛采用的模式，采用双机备份后主节点挂掉了后从节点可以接替主机继续服务。所以这种模式比单节点的要可靠得多。
下面看一下怎么一步步搭建 MongoDB 的主从复制节点：
1. 准备两台机器 10.43.159.56 和 10.43.159.58。10.43.159.56 当作主节点，10.43.159.58 作为从节点。
2. 分别下载 MongoDB 安装程序包。在 10.43.159.56 上建立文件夹 /data/MongoDBtest/master，10.43.159.58 建立文件夹 /data/MongoDBtest/slave。
3. 在 10.43.159.56 启动 MongoDB 主节点程序。注意后面的这个“ndash;master”参数，标示主节点：
mongod ndash;dbpath /data/MongoDBtest/master ndash;master输出日志如下，成功：
[initandlisten] MongoDB starting :pid=18285 port=27017 dbpath=/data/MongoDBtest/master master=14. 在 10.43.159.58 启动 MongoDB 从节点程序。关键配置：指定主节点 ip 地址和端口 ndash;source 10.43.159.56:27017 和标示从节点 ndash;slave 参数：
mongod ndash;dbpath /data/MongoDBtest/slave ndash;slave ndash;source 10.43.159.56:27017输出日志如下，成功：
[initandlisten] MongoDB starting : pid=17888port=27017 dbpath=/data/MongoDBtest/slave slave=1日志显示从节点从主节点同步复制数据：
[replslave] repl: from host: 10.43.159.56:27017这样，主从结构的 MongoDB 集群就搭建好了，是不是很简单？
下面我们来看看这个集群能做什么？先登录到从节点 shell 上，执行插入数据：
mongo 127.0.0.1:27017 db.testdb.insert({test3 : testval3}); not master可以看到 MongoDB 的从节点是只能读，不能执行写操作的。
那么如果主服务器挂掉，从服务器可以接替工作吗？
可以试一下，强制关掉主节点上的 MongoDB 进程，登录在从节点上，再次执行插入数据：
db.testdb.insert({test3 : testval3}); not master看来从节点并没有自动接替主节点的工作，那就只有人工处理了，停止从节点，再以 master 的方式启动从节点，由于从节点上数据跟主节点一样，此时从节点是可以替代主节点工作的，这属于人工切换。
此外，我们可以搭建多个从节点，实现数据库的读写分离，比如主节点负责写，多个从节点负责读，对于移动 APP，绝大部分操作都是读操作，可以实现负荷分担。
那么，搭建了这套主从结构的集群是不是就能应付商用环境呢？我们发现还是有几个问题亟待解决的：
主节点挂了能否自动切换连接？目前需要手工切换。
主节点的写压力过大如何解决？
从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？
就算对从节点路由实施路由访问策略能否做到自动扩展？
解决这几个问题就要靠下面介绍的副本集模式了。
副本模式
MongoDB 官方已经不建议使用主从模式了，替代方案是采用副本集的模式，那什么是副本集呢？简单地说，副本集就是有自动故障恢复功能的主从集群，或者说主从模式其实就是一个单副本的应用，没有很好的扩展性和容错性。而副本集具有多个副本保证了容错性，就算一个副本挂掉了还有很多副本存在，更棒的是副本集很多地方都是自动化的，它为你做了很多管理工作。聪明的读者已经发现，主从模式的 *** 个问题手工切换已经得到解决了，难怪 MongoDB 官方强烈推荐使用这种模式。我们来看看 MongoDB 副本集的架构图：
由图可以看到客户端连接到整个副本集，不关心具体哪一台机器是否挂掉。主服务器负责整个副本集的读写，副本集定期同步数据备份，一旦主节点挂掉，副本节点就会选举一个新的主服务器，这一切对于应用服务器不需要关心。我们看一下主服务器挂掉后的架构：
副本集中的副本节点通过心跳机制检测到主节点挂掉后，就会在集群内发起主节点的选举机制，自动选举一位新的主服务器。So Cool！让我们赶紧来部署一下！
官方推荐的副本集机器数量为至少 3 个（官方说副本集数量 *** 是奇数），那我们也按照这个数量配置测试。
1. 准备三台机器 10.43.159.56、10.43.159.58、10.43.159.60。10.43.159.56 当作副本集主节点，10.43.159.58、10.43.159.60 作为副本集副本节点。
2. 分别在每台机器上建立 MongoDB 副本集测试文件夹
3. 下载安装 MongoDB 的安装程序包
4. 分别在每台机器上启动 MongoDB
给你的副本集取个名字吧，比如这里叫 test：
/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongod --dbpath /data/MongoDBtest/replset/data --replSet test从日志可以看出副本集还没有初始化。
5. 初始化副本集
在三台机器上任意一台机器登陆 MongoDB：
/data/MongoDBtest/MongoDB-linux-x86_64-2.4.8/bin/mongo使用 admin 数据库：
use admin定义副本集配置变量，这里的 _id:”test”和上面命令参数“ndash;replSet test”要保持一致：
config = { _id: test , members:[ ... {_id:0,host: 10.43.159.56:27017}, ... {_id:1,host: 10.43.159.58:27017}, ... {_id:2,host: 10.43.159.60:27017}] ... }初始化副本集配置：
rs.initiate(config);输出成功：
{ info : Config now saved locally. Should come online in about a minute. , ok : 1 }查看日志，副本集启动成功后，56 为主节点 PRIMARY，58、60 为副本节点 SECONDARY，注意这里是三个节点共同选举出的主节点，有一定随机性。
查看集群节点的状态：
rs.status();整个副本集已经搭建成功了。是不是超级简单？
副本集模式的 MongoDB 不仅搭建简单，而且功能强大。现在回头看看这种模式能否解决我们前面遗留的问题：主节点挂了能否自动切换连接？
先测试副本集数据复制功能是否正常
首先在主节点 56 上插入数据，然后再副本节点上查看数据，发现日志报错：
error: { $err : not master and slaveOk=false , code : 13435 } at src/mongo/shell/query.js:128这是因为默认只从主节点读写数据，副本不允许读，只要设置副本可以读即可。在副本节点上执行：rs.slaveOk()，然后查询数据，发现主节点的数据已经同步过来了。
再测试下副本集的故障转移功能
先停掉主节点 56 上的进程，可以看到 58 和 60 节点上的日志显示的就是投票过程。再执行 rs.status() 可以看到集群状态更新了，56 为不可达，58 成为主节点，60 还是副本。再启动 56 节点，发现还是 58 为主节点，56 变为副本节点。这样就解决了 *** 个故障自动转移的问题。
那么，对于主节点读写压力过大，如何解决呢？常见的解决方案是读写分离，MongoDB 副本集的读写分离如何做呢？
看图说话：
对于移动 APP 的场景，通常写操作远没有读操作多，所以一台主节点负责写，两台副本节点负责读。从哪个节点读，完全可以由客户端选择，数据读取参数一共有五类（Primary、PrimaryPreferred、Secondary、SecondaryPreferred、Nearest）：
Primary：默认参数，只从主节点上进行读取操作；
PrimaryPreferred：大部分从主节点上读取数据，只有主节点不可用时从 Secondary 节点读取数据。
Secondary：只从 Secondary 节点上进行读取操作，存在的问题是 Secondary 节点的数据会比 Primary 节点数据“旧”。
SecondaryPreferred：优先从 Secondary 节点进行读取操作，Secondary 节点不可用时从主节点读取数据；
Nearest：不管是主节点、Secondary 节点，从网络延迟 *** 的节点上读取数据。
典型的副本集组网中，除了有副本节点，还有其他角色，比如仲裁节点，如下图：
其中的仲裁节点不存储数据，只是负责故障转移的群体投票，这样就少了数据复制的压力。此外还有 Secondary-Only、Hidden、Delayed、Non-Voting 等角色。
Secondary-Only：不能成为 Primary 节点，只能作为 Secondary 副本节点，防止一些性能不高的节点成为主节点。
Hidden：这类节点是不能够被客户端制定 IP 引用，也不能被设置为主节点，但是可以投票，一般用于备份数据。
Delayed：可以指定一个时间延迟从 Primary 节点同步数据。主要用于备份数据，如果实时同步，误删除数据马上同步到从节点，恢复又恢复不了。
Non-Voting：没有选举权的 Secondary 节点，纯粹的备份数据节点。
以上就是 MongoDB 中怎么实现集群，丸趣 TV 小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注丸趣 TV 行业资讯频道。
