java mongodb的MongoOptions生产级配置

• autoConnectRetry仅仅意味着驱动程序会自动尝试重新连接到意外断开连接后在服务器（一个或多个）。在生产环境中，您通常需要将此设置为true。

• connectionsPerHost是物理连接的单一实例蒙戈（它的单，所以你通常每个应用程序的话）能够建立到的mongod/mongos处理量。在撰写本文时，即使实际查询吞吐量较低，Java驱动程序也会建立这种连接数量（换句话说，您将看到mongostat中的“conn”统计值上升，直到它达到每个应用程序服务器的这个数量）。

  在大多数情况下，没有必要将此设置为高于100，但此设置是其中一项“测试并看到”的内容。请注意，您必须确保您设置足够的这种低使连接到您服务器的总量不超过

  db.serverStatus().connections.available

  在生产我们目前有这个在40

• connectTimeout。由于名称表示毫秒数，驱动程序将在连接尝试中止之前等待。设置超时时间（15-30秒），除非有一个现实的，预期的机会，这将成为其他成功的连接尝试。通常，如果连接尝试时间超过几秒，则网络基础结构无法实现高吞吐量。

• maxWaitTime。线程等待连接池上可用连接的数量，如果不及时发生，则会引发异常。保持默认。

• 了socketTimeout。标准套接字超时值。设置为60秒（60000）。

• threadsAllowedToBlockForConnectionMultiplier。 connectionsPerHost的倍数，表示如果池当前耗尽，允许等待连接变为可用的线程数。这是会导致“com.mongodb.DBPortPool $ SemaphoresOut：Out of semaphores获取db连接”异常的设置。一旦此线程队列超过threadsAllowedToBlockForConnectionMultiplier值，它将抛出此异常。例如，如果connectionsPerHost为10，并且此值为5，则在抛出上述异常之前，最多可有50个线程阻塞。

  如果你希望在吞吐量大的峰值，可能会导致大队列暂时增加该值。正因为这个原因，我们目前在1500点。如果您的查询负载一直超过服务器，那么您应该相应地改善硬件/扩展情况。

• readPreference。 （更新2.8+）用于确定默认读取偏好和替换“slaveOk”。通过一种类工厂方法设置ReadPreference。 最常见设置的完整描述可以在这个帖子

• W¯¯的末尾。 （更新，2.6+）该值确定写入的“安全性”。当此值为-1时，无论网络或数据库错误如何，写入都不会报告任何错误。 WriteConcern.NONE是适合此预定义的WriteConcern。如果w是0，那么网络错误将使写入失败，但mongo错误不会。这通常被称为“火灾和遗忘”写入，并应在性能比一致性和耐久性更重要时使用。为此模式使用WriteConcern.NORMAL。

  如果把W为1或更高的写入被认为是安全的。安全写入执行写入操作，然后通过向服务器发送请求进行跟踪，以确保写入成功或检索到错误值（如果没有写入）（换言之，写入后发送getLastError（）命令）。请注意，在此getLastError（）命令完成之前，连接被保留。作为其中的一个结果和附加命令的吞吐量将signficantly低于以w < = 0。1完全相同的MongoDB的W值保证写入成功（或失败核查的），你发送的写入实例写道。

  在副本集的情况下，您可以使用更高的值来告诉MongoDB在返回之前将写入发送到副本集的至少“w”个成员（或更准确地说，等待写入的复制“w”成员）。您还可以将w设置为字符串“majority”，它告诉MongoDB执行写入大部分副本集成员（WriteConcern.MAJORITY）的操作。通常，您应该将其设置为1，除非您需要原始性能（-1或0）或复制写入（> 1）。高于1的值对写入吞吐量有相当大的影响。

• FSYNC。强制mongo在启用每次写入后刷新到磁盘的耐久性选项。我从来没有遇到与写入积压相关的任何持久性问题，所以我们在生产中使用了这个错误（缺省值）。

• j * （NEW 2.7+） *。布尔值，当设置为true时，会强制MongoDB在返回之前等待成功的日记组提交。如果您启用了日记功能，则可以启用此功能以获得更多耐用性。请参阅http://www.mongodb.org/display/DOCS/Journaling以查看日志可以获取什么内容（以及为什么您可能需要启用此标志）。

ReadPreference 的ReadPreference类允许您配置什么的mongod，如果你是副本集工作查询路由实例。下列选项：

• ReadPreference.primary（）：所有读取到只有repset主要成员。如果您要求所有查询返回一致的（最近写入的）数据，请使用此选项。这是默认设置。

• ReadPreference.primaryPreferred（）：如果可能，所有读取转到repset主成员，但可以查询次要成员，如果主节点不可用。因此，如果主服务器变得不可用，则读取变为最终一致，但只有当主服务器不可用时。

• ReadPreference.secondary（）：所有读取转到次级repset成员，主要成员仅用于写入。只有在最终一致读取的情况下才能使用它。额外的repset成员可用于扩展阅读性能，尽管repset可能有（投票）成员的数量有限制。

• ReadPreference.secondaryPreferred（）：如果其中任何一个可用，所有读取都转到次级repset成员。主要成员专门用于写入，除非所有次要成员都不可用。除了用于读取的主要成员回退以外，它与ReadPreference.secondary（）相同。

• ReadPreference.nearest（）：读取转到可用于数据库客户端的最近的repset成员。仅在最终一致性读取可接受时才使用。最近的成员是客户端和各种repset成员之间延迟最低的成员。由于忙碌的成员最终会有更高的延迟，这个应该也会自动平衡读取负载，尽管在我的经验中，如果成员延迟相对一致，secondary（Preferred）看起来会更好。