单分片MongoDB集群Secondary节点读请求负载不均是什么原因？

驱动层面原因 #

• 最小延迟选择器默认策略偏置：Mongo Java Driver默认使用LatencyMinimizingServerSelector做节点选择，会优先选择延迟低于「最小节点延迟 + 允许延迟窗口（默认15ms）」的节点。如果两个Secondary节点的网络延迟差值长期超过15ms，驱动会持续将请求打到延迟更低的节点，不会做负载分摊。
• localThreshold配置不合理：驱动的localThreshold（本地阈值）参数默认15ms，若两个Secondary和应用服务器的网络延迟差超过该阈值，就会出现流量倾斜，可通过MongoClientSettings的localThreshold配置项调整阈值范围。
• 客户端实例初始化不规范：如果应用侧没有全局复用Mongo客户端单例，部分请求初始化新的客户端实例，新实例首次节点探测的随机/延迟逻辑可能出现偏置，累积后导致整体流量不均。

集群层面原因 #

• Secondary节点硬件/配置差异：如果两个节点的CPU、内存、磁盘IO性能不一致，性能更差的节点请求处理慢，驱动的延迟探测会判定它延迟更高，逐步减少分配给它的请求量。
• 同步延迟差值超过最大过期阈值：若其中一个Secondary的oplog同步延迟长期高于另一个，且读偏好配置了maxStalenessSeconds（最大可接受过期时间），驱动会自动排除延迟超标的节点，导致请求全部打到同步更及时的节点。
• 标签集匹配优先级差异：如果读偏好配置了附加节点标签集，两个Secondary的标签匹配度不同，驱动会优先选择匹配度更高的节点，也会引发流量倾斜。

业务请求层面原因 #

• 大查询分布不均：如果存在大量耗时久的大查询，且大部分落到其中一个节点上，会导致该节点查询数统计低但CPU占用高，反之如果小查询集中落到一个节点，会出现查询数高但CPU占用低的倾斜表现。
• 会话连接粘性问题：部分使用了会话（Session）或事务的请求，驱动会保证同一会话的请求落到同一个节点避免读不一致，如果大量长会话集中绑定某一个节点，也会出现流量不均。

内容的提问来源于stack exchange，提问作者Avinash Vundyala