MongoDB Replica Sets 深入研究：保障数据高可用性和容错性 (mongodb数据库)

简介

MongoDB Replica Set是一组包含多个成员的数据库系统，这些成员共同复制和维护相同的数据集。Replica Sets提供高可用性、容错性和扩展能力，使其成为关键任务应用程序的理想选择。

Replica Set架构

Replica Set由以下成员组成：Primary: 负责处理读写操作。Secondary: 从Primary复制数据的只读成员。Arbiter: 不存储数据，仅参与副本集选举。成员之间通过复制操作保持数据同步。Primary将写入操作应用到其数据集，然后将这些更改复制到Secondaries。Secondaries从Primary拉取更改并应用到自己的数据集。

高可用性

Replica Sets的高可用性特性体现在：故障转移: 如果Primary发生故障，Secondary将自动提升为Primary。自动故障检测: Replica Sets会定期监控成员的健康状况，并在检测到故障时触发故障转移。数据一致性: 复制操作确保Secondaries始终与Primary保持相同的数据副本。

容错性

Replica Sets的容错性特性体现在：多副本: 数据在多个成员之间复制，即使一个或多个成员发生故障，数据也不会丢失。副本隔离: Replica Set中的成员是相互隔离的，这意味着一个成员的故障不会影响其他成员。延迟复制: Secondaries可以配置为落后于Primary，这有助于在发生故障时提供数据恢复能力。

扩展能力

Replica Sets可以通过添加或删除成员来轻松扩展。以下是如何扩展Replica Set：添加成员: 添加成员可增加Replica Set的容量和冗余。删除成员: 移除成员可减少Replica Set的容量和冗余。

操作

管理Replica Set需要一些操作任务：初始化: 创建Replica Set并设置成员。添加成员: 将新成员添加到Replica Set。删除成员: 从Replica Set中移除成员。监控: 监控Replica Set的健康状况和性能。故障排除: 故障转移或数据不一致等问题进行故障排除。

用例

Replica Sets在以下用例中非常有用：高可用性应用程序: 需要确保数据持续可用性的应用程序。容错性应用程序: 需要能够承受成员故障的应用程序。分布式应用程序: 需要在多个数据中心或区域中复制数据的应用程序。

结论

MongoDB Replica Sets是一种强大的机制，可以为MongoDB部署提供高可用性、容错性和扩展能力。通过理解Replica Sets的架构、特性和操作，您可以充分利用这些优势，并确保您的应用程序和数据始终可用且受到保护。

---

谈谈redis，memcache，mongodb的区别和具体应用场景

从以下几个维度，对 redis、memcache、mongoDB 做了对比。 1、性能都比较高，性能对我们来说应该都不是瓶颈。 总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。 2、操作的便利性memcache 数据结构单一。 （key-value）redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，hash 等数据结构的存储。 mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。 3、内存空间的大小和数据量的大小redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过期时间（类似 memcache）memcache 可以修改最大可用内存,采用 LRU 算法。 Memcached 代理软件 magent，比如建立10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2 -b10.1.2.3 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务不要和别的服务在一起。 4、可用性（单点问题）对于单点问题，redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。 一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环状的算法，解决单点故障引起的抖动问题。 mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。 5、可靠性（持久化）对于数据持久化和数据恢复，redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影响memcache 不支持，通常用在做缓存,提升性能；MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性6、数据一致性（事务支持）Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行mongoDB 不支持事务7、数据分析mongoDB 内置了数据分析的功能(mapreduce),其他不支持8、应用场景redis：数据量较小的更性能操作和运算上memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用 sharding）MongoDB:主要解决海量数据的访问效率问题。 表格比较：memcache redis 类型 内存数据库 内存数据库数据类型 在定义 value 时就要固定数据类型 不需要有字符串，链表，集 合和有序集合虚拟内存 不支持 支持过期策略 支持 支持分布式 magent master-slave，一主一从或一主多从存储数据安全 不支持 使用 save 存储到 中灾难恢复 不支持 append only file(aof)用于数据恢复性能1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。 当然，memcache 也可用于缓存其他东西，例如图片等等。 2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。 3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。 4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。 Redis 可以通过例如 expire 设定，例如 expire name 10。 5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。 都可以一主一从。 6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。 7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。 Memecache 端口 yum -y install memcachedyum -y install php-pecl-memcache/etc/init.d/memcached start memcached -d -p -u memcached -m 64 -c 1024 -P /var/run/memcached/-d 启动一个守护进程-p 端口-m 分配的内存是 M-c 最大运行并发数-P memcache 的 pid//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间//delete 5 是 timeout <?php$memcache = new Memcache; $memcache -> connect(127.0.0.1, ); $memcache -> set(name,yang,0,30);if(!$memcache->add(name,susan,0, 30)) {//echo susan is exist; }$memcache -> replace(name, lion, 0, 300); echo $memcache -> get(name);//$memcache -> delete(name, 5);printf stats\r\n | nc 127.0.0.1 telnet localhost stats quit 退出Redis 的配置文件 端口 6379/etc/ 启动 Redisredis-server /etc/ 插入一个值redis-cli set test 获取键值redis-cli get test 关闭 Redisredis-cli shutdown 关闭所有redis-cli -p 6379 shutdown <?php$redis=new Redis(); $redis->connect(127.0.0.1,6379); $redis->set(test, Hello World); echo $redis->get(test); Mongodbapt-get install mongo mongo 可以进入 shell 命令行pecl install mongo Mongodb 类似 phpmyadmin 操作平台 RockMongo

redis和mongodb哪个简单

redis、memcahce 比较相似，但与 mongodb 完全不同，几乎没有可比性。 总的来说 redis/memcache 是基于内存的，讲究的是性能，多用作缓存层，比如说存放session。 而 mongodb 是面向文档的，存储的是类似JSON的非结构化数据，查询起来非常方便，开发效率高，比较类似传统SQL关系型数据库。 从以下几个维度，对redis、memcache、mongoDB 做了对比：体积Redis是一个基于内存的键值数据库，它由C语言实现的，以单线程异步的方式工作，与Nginx/ NodeJS工作原理近似。 所以文件非常小。 编绎出来的主文件还不到 2Mb，在 Linux 服务器上初始只需要占用1Mb左右的内存。 Mongodb安装包则要大的多，跟mySQL差不多，都是百兆级的。 性能都比较高，性能对我们来说应该都不是瓶颈总体来讲，TPS方面redis和memcache差不多，要大于mongodb操作的便利性memcache数据结构单一redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富推荐学习《python教程》内存空间的大小和数据量的大小redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）memcache可以修改最大可用内存,采用LRU算法mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起可用性（单点问题）对于单点问题，redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题，所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。 一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡Memcache本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。 mongoDB支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制。 可靠性（持久化）对于数据持久化和数据恢复，redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响memcache不支持，通常用在做缓存,提升性能；MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性，备份还原方法7.数据一致性（事务支持）Memcache 在并发场景下，用cas保证一致性redis事务支持比较弱，只能保证事务中的每个操作连续执行mongoDB不支持事务8.数据分析mongoDB内置了数据分析的功能(mapreduce),其他不支持9.应用场景redis：数据量较小的更性能操作和运算上memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding）MongoDB:主要解决海量数据的访问效率问题。

【mongoDB】mongoDB的高可用、一致性

高可用是MongoDB最核心的功能之一，相信很多同学也是因为这一特性才想深入了解它的。 那么本节就来说下MongoDB通过哪些方式来实现它的高可用，然后给予这些特性我们可以实现什么程度的高可用。 相信一旦提到高可用，浮现在大家脑海里会有如下几个问题： 那么，带着这些问题，我们继续看下去，看完大家应该会对这些问题有所了解了。 MongoDB高可用的基础是复制集群，复制集群本质来说就是一份数据存多份，保证一台机器挂掉了数据不会丢失。 一个副本集至少有3个节点组成： 从上面的节点类型可以看出，一个三节点的复制集群可能是PSS或者PSA结构。 PSA结构优点是节约成本，但是缺点是Primary挂掉之后，一些依赖 majority（多数）特性的写功能出问题，因此一般不建议使用。 复制集群确保数据一致性的核心设计是： 从上面4点我们可以得出 MongoDB 高可用的如下结论： MongoDB宕机重启之后可以通过checkpoint快速恢复上一个60s之前的数据。 MongoDB最后一个checkpoint到宕机期间的数据可以通过Journal日志回放恢复。 Journal日志因为是100ms刷盘一次，因此至多会丢失100ms的数据 （这个可以通过WriteConcern的参数控制不丢失，只是性能会受影响，适合可靠性要求非常严格的场景） 如果在写数据开启了多数写，那么就算Primary宕机了也是至多丢失100ms数据（可避免，同上）。 分布式系统必须要面对的一个问题就是数据的一致性和高可用，针对这个问题有一个非常著名的理论就是CAP理论。 CAP理论的核心结论是：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 关于CAP理论在网上有非常多的论述，这里也不赘述。 CAP理论提出了分布式系统必须面临的问题，但是我们也不可能因为这个问题就不用分布式系统。 因此，BASE（Basically Available基本可用、Soft state软状态、Eventually consistent最终一致性）理论被提出来了。 BASE理论是在一致性和可用性上的平衡，现在大部分分布式系统都是基于 BASE理论设计的，当然MongoDB也是遵循此理论的。 MongoDB为了保证可用性和分区容错性，采用的是副本集的方式，这种模式就必须要解决的一个问题就是怎样快速在系统启动和Primary发生异常时选取一个合适的主节点。 这里潜在着多个问题： MongoDB的选举算法是基于Raft协议的改进，Raft协议将分布式集群里面的节点有3种状态： leader：就是Primary节点，负责整个集群的写操作。 candidate：候选者，在Primary节点挂掉之后，参与竞选的节点。 只有选举期间才会存在，是个临时状态。 follower：就是Secondary节点，被动的从Primary节点拉取更新数据。 节点的状态变化是：正常情况下只有一个leader和多个flower，当leader挂掉了，那么flower里面就会有部分节点成为candidate参与竞选。 当某个candidate竞选成功之后就成为新的leader，而其他candidate回到flower状态。 具体状态机如下： Raft协议中有两个核心RPC协议分别应用在选举阶段和正常阶段： 请求投票：选举阶段，candidate向其他节点发起请求，请求对方给自己投票。 追加条目：正常阶段，leader节点向follower节点发起请求，告诉对方有数据更新，同时作为心跳机制来向所有follower宣示自己的地位。 如果follower在一定时间内没有收到该请求就会启动新一轮的选举投票。 Raft协议规定了在选举阶段的投票规则： 一个节点，在一个选举周期（Term）内只能给一个candidate节点投赞成票，且先到先得。 只有在candidate节点的oplog领先或和自己相同时才投赞成票。 一轮完整的选举过程包含如下内容： 以上就是目前掌握的MongoDB的选举机制，其中有个问题暂时还未得到解答，就是最后一个，怎样确保选出的Primary是最合适的那一个? 因为，从前面的协议来看，存在一个逻辑bug：由于follower转换成candidate是随机并行的，再加上先到先得的投票机制会导致选出一个次优的节点成为Primary。 针对Raft协议的这个问题，下来查询了一些资料，结论是： Raft协议确实不保证选举出来的Primary节点是最优的。 MongoDB通过在选举成功，到新Primary即位之前，新增了一个 catchup（追赶）操作来解决。 即在节点获取投票胜利之后，会先检查其它节点是否有比自己更新的oplog，如果没有就直接即位，如果有就先把数据同步过来再即位。 MongoDB的主从同步机制是确保数据一致性和可靠性的重要机制。 其同步的基础是oplog，类似MySQL的binlog，但是也有一些差异，oplog虽然叫log但并不是一个文件，而是一个集合（Collection）。 同时由于 oplog 的并行写入，存在尾部乱序和空洞现象，具体来说就是oplog里面的数据顺序可能是和实际数据顺序不一致，并且存在时间的不连续问题。 为了解决这个问题，MongoDB采用的是混合逻辑时钟（HLC）来解决的，HLC不止解决乱序和空洞问题，同时也是用来解决分布式系统上事务一致性的方案。 主从同步的本质实际上就是，Primary节点接收客户端请求，将更新操作写到oplog，然后Secondary从同步源拉取oplog并本地回放，实现数据的同步。 同步源是指节点拉取oplog的源节点，这个节点不一定是Primary，链式复制模式下就可能是任何节点。 节点的同步源选取是一个非常复杂的过程，大致上来说是： 在同步源选取时有些特殊情况： 用户可以为节点指定同步源。 如果关闭链式复制，所有Secondary节点的同步源都是Primary节点。 如果从同步源拉取出错了，会被短期加入黑名单。 整个拉取和回放的逻辑非常复杂，这里根据自己的理解简化说明，如果想了解更多知识可以参考《MongoDB复制技术内幕》 节点有一个专门拉取oplog的线程，通过Exhausted cursor从同步源拉取 oplog。 拉取下来之后，并不会执行回放执行，而是会将其丢到一个本地 的阻塞队列中。 然后有多个具体的执行线程，从阻塞队列中取出oplog并执行。 在取出过程中，同一个Collection的oplog一定会被同一个线程取出执行，线程会尽可能的合并连续的插入命令。 整个回放的执行过程，大致为先加锁，然后写本店oplog，然后将oplog刷盘（WAL机制），最后更新自己的最新opTime。 MongoDB全方位知识图谱

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！