分片集群 Mongos 负载不均解析及应对方案

业务背景

云数据库 MongoDB 分片集群提供了多个 Mongos 节点，负责接收所有客户端应用程序的连接查询请求，并将请求路由到集群内部对应的分片上，同时会把接收到的响应拼装起来返回到客户端。用户通过一个 VIP 或多个 VIP 等方式接入负载均衡数据库实例，将流量自动分发至不同的 Mongos 执行，以加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

负载均衡原理

用户程序连接到一个负载均衡服务（VIP），通过一个 VIP 来屏蔽后端的多个 RSIP（ Real Server IP ）。云数据库 MongoDB 负载均衡服务通过源 IP、源端口、目标 IP、目标端口、通信协议5元组 Hash 策略，将不同请求源 IP 路由于不同的 Mongos 节点。如果后台出现 RSIP 变更，会有自动化的流程变更 VIP 和 RSIP 的映射关系，对用户无感知，接入简单。

批量扫描 getMore 问题

当 MongoDB 无法将 find 结果一次性返回时，会优先返回第一批数据 + cursorID，客户端通过这个 cursorID 不断 getMore 迭代剩余的数据。所以一次批量扫描请求可能会对应1次 find 请求和多次 getMore 请求，并通过 cursorID 关联。

因此必须要保证 find 及其相关联的 getMore 请求发往同一个 Mongos 节点。而如果 getMore 请求发给了其他的 Mongos 节点，会因为找不到 Cursor 返回 CursorNotFound 错误，如下图所示。

事务操作问题

MongoDB 在 4.2 版本支持了分布式事务，用户可以连接 Mongos 节点发起事务操作。在 startTransaction 和 commitTransaction/abortTransaction 之间可以执行多次 读写操作，Mongos 在内存中记录了事务中每次请求携带的 logicalSessionId 和 txnId 等元数据来维护上下文关系。因此， 决定了需要保证事务中的每个操作都发到同一个 Mongos 上执行。

云数据库 MongoDB 负载均衡策略

基于批量扫描 getMore 问题及其事务操作问题的考虑，云数据库 MongoDB 负载均衡 Hash 策略根据访问端（一般是 CVM）IP 信息来均衡分流：一个源 IP 的请求都会落在同一个 Mongos 上，保证 getMore() 和事务操作在同一个上下文进行。

一般生产环境中访问端 IP 较多，这种策略效果较好。但是当访问端 IP 较少的情况下，特别是在压测场景下，容易引起 Mongos 负载不均衡的问题。

Mongos 负载不均解决方案

如果您不想使用默认的云数据库 MongoDB 的负载均衡策略，可开通 Mongos 访问地址。在实例当前的 VIP 下面，系统将给不同的 Mongos 节点绑定不同的 VPORT，用户可灵活控制 Mongos 的请求分配。并且，Mongos 故障后系统将重新绑定新的 Mongos 进程，VIP 和 VPORT 地址不会变化，不影响原有的负载均衡访问地址。具体操作，请参见 开通 Mongos 访问地址。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!