41｜MongoDB：MongoDB 是怎么做到高可用的？

我也请教老师几个问题： 1.“引入仲裁节点，就类似于 Elasticsearch 里的仅投票节点。”，es我不是很懂，是不是类似redis的哨兵节点？ 2. redis集群模式迁移时支持重定向，那mongo在迁移块的时候，可以访问么？ 跟着老师的收获： MongoDB的核心：快速横向扩展和灵活的文档模型。 主从同步原理：通过oplog日志传输，oplog日志是整条数据set日志，比redis的AOF日志还夸张@。@。另外MongoDB的日志超过配置大小，直接被删除这个时候，这个从节点就只能重新发起一次全量的数据同步了。redis主从同步是环形缓冲区，mysql是日志循环组；MongoDB好不负责啊？ 落盘机制：和kafka很像，主从同步完成和落盘完成，但配置多了一个超时时间，在超时之后 MongoDB 就直接返回一个错误。 %如何逐步提高中间件的可用性% 1.如果是单节点，那么可以使用一主两从，通过主从同步提高可用性。缺点是需要手动把从节点升级为主节点，和redis一样 2.引入仲裁节点和redis哨兵一样，监控/选主；仲裁节点被部署在轻量级的服务器上，成本非常低。redis这里涉及了判定下线以及哨兵选主、新从节点切到主节点。 3.引入主从结构的配置服务器，如果配置服务器挂了整个集群就基本不可用了。这个redis没有。。无中心化和中心化的区别。 4.多数据中心的主从结构，除了同城机房从节点，还可以在其他节点部署从节点，提高可用性，还可以配置从节点的优先级，同城优先。 5.分片集群既可以提高性能，又可以提高可用性。而在 MongoDB 里面，它会自动平衡不同分片的数据。 分片集群是 MongoDB 的分布式版本，相较副本集，分片集群数据被均衡的分布在不同分片中。 Config Servers：配置服务器 Mongos：路由服务 Shard：每个分片是整体数据的一部分子集 每个分片又由多个块（chunk）组成。在最新版本的默认情况下，一个块的大小是 128 MB。数据太多和文档太多，就会被自动重平衡；根据内部阈值表的规则，触发块迁移，就像AVL一样。迁移过程由MongoDB自动实现。

请教老师几个问题： Q1：采用MongoDB，主要是因为可以动态增删字段吗？ Q2：仲裁节点，不单独部署，而部署在其他主要机器上吗？ 比如，一台机器部署的是MySQL，或者某一个业务的服务，仲裁节点会部署在此机器上，而不会单独部署在一个机器上，对吗？ 对于ES的选举节点，应该也是一样的。 Q3：分片多但没有超过128M，也会分片吗？分片阈值是可配置的吗？ Q4：阈值定义中：“少于20块”，阈值为2。以此为例，“少于20块”是分片中的块数量？还是集合中的块数量？“如果一个集合里面最大的分片有 9 个块，而最少的集合有 7 个块” ，这句话中，“最少的集合”应该是笔误，应该是“最少的分片”吧。 Q5：配置服务器是采用主从结构吗？为什么可以在主节点崩溃以后还可以继续服务？是自动切换吗？ Q6：某些操作导致oplog很大的时候，会表现为响应时间长吗？