作者回复: “MongoDB官方好像是建议1主1从1arbiter” 请提供相应的文章。 主节点挂了以后，两个从节点的投票算法会防止你说的现象发生。具体来说，如果两个从节点条件完全一样，那么第一个主张的节点就获胜。如果两个从节点同时主张自己，那么两个人同时放弃，并用一个随机值等待一小段时间（数秒），然后重试。所以总有一个节点会在另一个之前选为主节点。

作者回复: 谢谢夸奖😊

作者回复: - 升级存储是最直接的方案，如PCIE + SSD - 注意索引的数量：索引越多写入越慢 - 分片： 增加写的节点来提供并发

作者回复: 通过水平扩展可以提高整体的吞吐量，但是单个（比如说，查询 id=1234 这条记录）查询是不会得到改善的。因为这个查询就是会在一个节点上发生。 提高单个查询性能就是把数据放在内存里，加上合适的索引可以来提升性能（降低读取延迟）

作者回复: 总数是看最初的配置，如你部署并配置了3个，虽然坏了一个，但是你的拓扑还是3节点， 按3节点的规则，剩下2个存活就可以正常工作。

作者回复: 对。读写分离的读一般指的是对时效性要求不高的读场景。如果要求高一般都建议读主节点。如果主节点性能扛不住，这个时候就要采用分片集群来分担压力(读和写)。

作者回复: 复制集也是集群，3个节点以上的高可用集群。数据不做分布式存储，只是主从热备

作者回复: 可以学习后面的writeConcern, 写事务 这一节，你就了解答案了。

作者回复: 1）是的会重新同步。节点之间判断是否需要同步是根据local库里的元数据决定的。里面记录了节点同步的状态信息，并不是看你实际存储的数据。 2）建议用SSL/TLS 加密链路就可以有效防止数据被窃取。 https://docs.mongodb.com/manual/tutorial/configure-ssl/index.html

作者回复: 主从复制会有延迟。常见因素： 1） 网络抖动 （没办法） 2）网络拥挤 （评估数据增量需求，给予足够的带宽） 3）节点之间延迟太长 4）主节点压力过大 （注意监控，压力过大要扩容） 5）从节点配置不均衡，低于主节点配置（尽量均衡）