我有一个应用程序，我的任务是设计一个 mongo 支持的数据存储。
应用程序的目标是以最快的加载时间提供最新的数据（没有陈旧的数据）。
数据大小约为数百万，应用程序写入繁重。
在选择给定 3 节点副本集（1 个主要副本、1 个辅助节点、1 个仲裁者）的读取策略时，我遇到了两种不同的策略来确定从何处获取读取 -
从次级读取以减少初级负载。使用writeConcern = REPLICA_SAFE，从而确保在主服务器和辅助服务器上完成写入。设置阅读偏好。到secondaryPreferred.
始终从主要读取。但在读取之前确保数据是主要的。所以设置 writeConcern= SAFE。读取首选项是默认值 - primaryPreferred。
在选择其中一个选项之前要考虑哪些事项。
根据文档REPLICA_SAFE是一个已弃用的术语，应替换为REPLICA_ACKNOWLEDGED。这里的另一个问题是这里的w值似乎是这个常数的2。
这对您的配置来说是个问题，因为您有一个主节点和一个辅助节点，以及一个仲裁器。如果节点出现故障或无法访问，并且级别设置为这样，它会寻求确认来自2 个节点的所有写入，其中不会有2 个节点可用。您可以通过这种方式将写操作挂起。
您的配置的更好情况是MAJORITY，因为无论节点数量如何，它都将确保写入主节点和辅助节点的“多数”。但是在您的情况下，如果您的一个节点已关闭或不可用，则任何涉及超过 PRIMARY 的写入问题都会阻止所有写入，因为您必须至少再有两个辅助节点可用，这样仍然会有“大多数”节点确认写入。或者删除 ARBITER 并拥有两个 SECONDARY 节点。
因此，您必须坚持默认情况w=1，即所有写入都向 PRIMARY 确认，除非您可以在一个SECONDARY 出现故障时处理写入失败。
您可以将读取首选项设置为secondaryPreferred，只要您接受“可能”读取过时或不是最新的数据表示，因为唯一真正的保证是写入主节点。一般复制注意事项仍然存在，因为节点的处理能力应该在某种程度上相等，否则这可能会由于您的查询操作而导致滞后或一般性能下降。
请记住，复制是为了冗余而实现的，而不是用于提高性能的系统。如果您正在寻找性能，那么也许考虑扩展您的系统硬件或实施分片来分配负载。