我的问题听起来可能过于笼统，但我准备好提供任何缺失的数据。
我们制作类似社交网络的东西。为了使读取性能更好并简化主实例的寿命，我们设置了
readPreference=secondaryPreferred
在我们的副本集中。但是有了这个，不能保证数据在你从那里读取之前被写入辅助实例，所以我们必须设置
w=3
选项。到目前为止，一切似乎都在工作，但我的本地副本集上的测量结果显示了以下插入统计信息。
Inserting 300 objects:
w=1 - 0.10s
w=3 - 1.31s
Insertion 5000 objects:
w=1 - 0.6s
w=3 - 14.6s
问题是，这种差异是预期的，还是我做错了什么？
性能差异是预期的，因为 w=3 意味着除了来自主节点的确认 (w=1) 之外，您还希望等待确认数据已成功复制到至少两个辅助节点。
为清楚起见，w = 1 仅表示您希望主节点确认操作已完成。如果发生任何错误，例如重复的密钥错误或网络错误，都将作为确认的一部分进行报告。
http://docs.mongodb.org/manual/reference/write-concern/
请参阅上面的链接，您可以看到较低的写入问题可以让您以安全性换取较低的延迟。
如果您想要更高级别的持久性或安全性，那么您可以使用 j=1 来等待确认您的操作已写入日志（允许从故障中恢复）。w > N 通过等待 > N 个副本成员的确认来提高安全性，以确保您的操作已成功复制到其他成员。所以要清楚， w > 1 并不是指示驱动程序写入副本的必要条件。如果您决定使用 w=N，请注意，如果副本集成员失败并低于 N，您可能会陷入糟糕的境地。w=majority 是一个更灵活的选择。
最后，您可能需要重新评估为什么要从辅助节点读取数据。由于 MongoDB 使用异步复制，辅助节点最终是一致的。如果您期望读取一致，那么从主数据库读取更有意义。如果您从辅助节点读取数据的原因是为了扩展，您应该考虑分片，因为这是扩展的主要机制。在辅助节点上分配负载很少会提高可伸缩性。操作被复制到副本，因此您不会从较低的写入负载中获得太多收益。有时分配不同类型的工作负载是有意义的（可能会导致更好的内存利用率）。例如，在辅助节点上运行 MR 作业可能是有意义的。副本集主要用于高可用性——容错提供自动故障转移和网络分区问题。