Node.js mongodb副本集如何与nodejs mongoose一起工作？

Techstack使用了nodejs、mongoose、mongodb

我正在开发一个可以处理许多DBR请求的产品。在每个月初，由于大量数据处理的高读/写请求，db请求较高。每个集合中用于服务这些读/写请求的目标记录数相当高。读是高的，但写不是那么高

因此，运行mongodb的实例的cpu利用率在这段时间内达到了90%以上的危险区域。唯一能让我度过这段时间的是希望是的，希望那个实例不会崩溃

我不是在垂直扩展，而是在寻找水平扩展的解决方案，这不是一个革命性的想法。我看了看复制集和碎片。这个问题只与复制集有关

我浏览了一些文档，我觉得我对replicaset的理解并不是它真正的工作方式

我已使用以下配置配置了我的复制集。我只想再添加一个实例，因为根据我现在的理解，如果我再添加一个实例，那么我的数据库可以通过分配负载来处理更多的读取请求，这可以将primaryNode上的CPU利用率至少降低30%。这种理解是正确的还是错误的？请分享你的想法

当我使用上面的配置启动replicaset并运行我的nodejs mongoose代码时，我遇到了一个问题。他们提出的解决方案是将上述配置更改为

var configuration = {
    _id : "testReplicaDB",
    members:[
        {_id:0,host:"validdomain.com:12017"},
        {_id:1,host:"validdomain.com:12018",arbiterOnly:true,buildIndexes:false},
        {_id:2,host:"validdomain.com:12019"}
    ]
}

问题1与mongoose Library在nodejsproject中编写的用于处理连接到replicaSet的数据库的编码相关

常量URI=mongodb://167.99.21.9:12017，167.99.21.9:12019/${DB}

我必须在mongoose连接uri字符串中指定我的mongodb实例的两个uri

当我查看将连接到replicaSet的nodejs mongoose代码时，我对它如何处理多节点有很多疑问

mongoose如何知道哪个ip是主节点

假设167.99.21.9:12019是primaryNode，而secondaryReplica上的rs.slaveOkfalse，因此secondaryNode无法为readRequests提供服务

在这种情况下，mongoose是否会触发到第一个uri167.99.21.9:12017，此实例是否会重定向到primaryNode，或者请求是否会返回到mongoose，然后mongoose会触发到167.99.21.9:12019的另一个请求

问题2

提到数据冗余能够处理高读取请求。假设secondaryNode已启用读取，并且

假设mongoose触发了对primaryNode的请求，primaryNode当时被读/写请求轰炸，而secondaryNode却无所事事，那么mongodb会自动将请求重定向到secondaryNode，还是该请求会失败并重定向回mongoose，这样mongoose就有责任向下一个可用节点触发另一个请求？ mongoose能否自动知道复制集中的哪个节点是空闲的？ 问题3

假设167.99.21.9:12017和167.99.21.9:12019实例都可用于ReadPreference.SecondaryPreferred或ReadPreference.nearest的读取请求，那么当secondaryNode被readRequests轰炸并且primaryNode的利用率达到20%时，负载是否会被分配？是这样吗？还是我的理解错了？replicaSet能否充当负载平衡器？如果没有，如何使其平衡负载

问题4

您可以在配置中看到DNS名称，这是否意味着当primaryNode将请求重定向到secondaryNode时，将进行DNS解析，然后使用与secondaryNode对应的IP，将请求重定向到secondaryNode？我的理解是对的还是错的？如果我的理解是正确的，这将引发另一系列问题

：|

我读文件的时候可能会错过很多细节。这是我得到答案的最后希望。因此，如果你知道这些问题的答案，请与我们分享

如果是这种情况，那么mongoose如何知道哪个ip是primaryReplicaset

没有主副本集，但是副本集中可以有一个主副本

每个MongoDB驱动程序查询连接字符串中指定的所有主机，以发现副本集的成员，以防一个或多个主机因任何原因不可用。当副本集的任何成员响应时，它会使用副本集当前成员的完整列表进行响应。然后，驱动程序知道复制集成员是什么，以及其中哪些成员当前是主成员（如果有）

secondaryReplica无法为读取请求提供服务

这根本不是真的。如果应用程序提供了合适的接口，任何数据承载节点都可以满足读取请求

在这种情况下，mongoose是否会触发到第一个uri167.99.21.9:12017，并且此实例是否会重定向到primaryReplicaset，或者请求是否会返回 到mongoose，然后mongoose将触发另一个到167.99.21.9:12019的请求

mongoose不直接与数据库通信。它使用MongoDB的驱动程序节点驱动程序来执行此操作。驱动程序连接到所有副本集成员，并将请求发送到相应的节点

例如，如果指定了主读取首选项，则驱动程序会将该查询发送到主读取首选项（如果存在）。如果指定了辅助读取首选项，则驱动程序会将该查询发送到辅助读取首选项（如果存在）

我假设167.99.21.9:12017和167.99.21.9:12019实例都可用于ReadPreference.secondary preferred或ReadPreference.nearest的读取请求

正确，任何节点都可以实现这些功能

负载可能会分布到各个区域

是和否。通常，复制副本可能有过时的数据。如果需要当前数据，则必须从主数据库读取。如果您不需要当前数据，则可以从辅助设备读取

如何使其平衡负载

您可以通过使用辅助读取或最近读取使应用程序平衡负载，前提是您的应用程序可以接收陈旧数据

如果mongoose触发了对primaryReplica的请求，primaryReplica被读/写请求轰炸，而secondaryReplica无所事事，那么mongodb会自动将请求重定向到secondaryReplica吗

否，主读不会更改为次读

特别是在您描述的场景中，辅助读取可能会过时，因此辅助读取可能会产生错误的结果

mongoose能否自动知道哪个副本是免费的

mongoose不跟踪部署状态，由驱动程序负责。驱动程序对选择负载较低的节点的支持有限，尽管这是根据网络延迟而不是CPU/内存/磁盘负载来衡量的，并且仅适用于

var configuration = {
    _id : "testReplicaDB",
    members:[
        {_id:0,host:"validdomain.com:12017"},
        {_id:1,host:"validdomain.com:12018",arbiterOnly:true,buildIndexes:false},
        {_id:2,host:"validdomain.com:12019"}
    ]
}

var configuration = {
    _id : "testReplicaDB",
    members:[
        {_id:0,host:"validdomain.com:12017"},
        {_id:1,host:"validdomain.com:12018",arbiterOnly:true,buildIndexes:false},
        {_id:2,host:"validdomain.com:12019"}
    ]
}