MongoDB 读偏好设置中增加最大有效延迟时间的参数

在某些情况下，将读请求发送给副本集的备份节点是合理的，例如，单个服务器无法处理应用的读压力，就可以把查询请求路由到可复制集中的多台服务器上。现在绝大部分 MongoDB 驱动支持读偏好设置（read preference；或翻译为读取首选项），用来告诉驱动从特定的节点读取数据。

1.副本集读偏好

primary — 这是默认的设置，表明只从可复制集的主节点读取数据，因此具有强一致性。如果可复制集有问题，并且没有可选举的从节点，就表示出现错误。

premaryPreferred — 设置了此参数的驱动会从主节点读取数据，除非某些原因使主节点不可用或者没有主节点，此时它会从从节点读取数据。此种设置下，读请求无法保证一致性。

secondary — 这个设置告诉驱动应该一直从从节点读取数据。这种设置对于我们想确保读请求不会影响主节点的写入请求时非常有用。如果没有可用的从节点，读请求会抛出异常。

secondarypreferred  — 读请求会发出到从节点，除非没有从节点可用，此时才会从主节点读取。

nearest   –  驱动会尝试从最近的可复制集成员节点读取读取数据，通过网络延迟判断。可以是主节点也可以是从节点。因此读请求只会发送给驱动认为最快通信的节点。

primary是唯一一个可以确保读一致的模式。因为写请求首先在主节点完成，从服务器的更新会有些延迟，所以可能在从节点无法找到刚刚在主节点写入的文档数据。

汇总以上知识，各偏好设置下读取数据请求所发往的节点如下所示：

2.有效最大延迟时间

MongoDB 3.4及更新的版本新增了maxStalenessSeconds设置。

副本集的从节点可能因为网络阻塞、磁盘吞吐低、长时间执行操作等，导致其落后于主节点。读设置maxStalenessSeconds选项让你对从节点读取定义了最大落后或“过期”时间。当从节点估计过期时间超过了maxStalenessSeconds,客户端会停止使用它进行读操作。

最大过期和primary模式不匹配，只有选择从节点成员读取操作才能应用。

当选择了使用maxStalenessSeconds进行读操作的服务端，客户端会通过比较从节点和主节点的最后一次写时间来估计从节点的过期程度。客户端会把连接指向估计落后小于等于maxStalenessSeconds的从节点。如果没有主节点，客户端使用从节点间的最近一次写操作来比较。

默认是没有最大过期时间并且客户端也不会在指向读操作时考虑从节点的落后。

注意：

必须定义maxStalenessSeconds的值大于等于90秒：定义一个更小的值会抛出异常。客户端通过定期检查每个副本集成员最后一次写时间来估计副本集过期程度。因为检查不频繁，所以估计是粗略的。因此，客户端不能强制maxStalenessSecconds小于90秒。

3.连接配置

副本集连接字符串格式

mongodb://username:password@host1:port1,host2:port2[,...,hostN:portN]/database?options

options 是连接配置中的可选项，replicaSet、readPreference、maxStalenessSeconds是其中的一个子项。

下面我们举一个例子来说明字符串是怎么配置的，测试环境的副本集信息如下：

账号信息如下：

如果希望程序读请求路由到从节点secondary，100秒为节点数据失效时间，此时C# 程序中connectionStr的字符串可以设置如下：

string connectionStr = "mongodb://mongousertest:testuserpwd@168.17.XXX.xx1:27017,168.17.XXX.xx2:27017/mongotestdb?replicaSet=repltest&readPreference=secondary&maxStalenessSeconds=100";

部分内容参考官网： https://docs.mongodb.com/manual/core/read-preference/index.html