巧用 maxTimeMS 办事端超时，避免承载亿级用户的腾讯云数据库MongoDB办事雪崩

腾讯云数据库MongoDB作为一款基于开源社区MongoDB版本的文档数据库产品，其承载着公司内外包括微信、看点、QQ音乐在内的亿级用户重量级APP产品。在某些场景的应用过程中，用户在客户端要求超时后会不断重试，可能导致办事端大量要求积压，出现恶性循环甚至导致办事雪崩。一般遇到这种情况，后台会自动检测并做办事降级，主动拒绝一部分用户要求，或者重启后端办事等举措来应对。但是这些措施对业务有损，或者不可自行恢复。

本文围绕 MongoDB 原生 maxTimeMS 特性和腾讯云MongoDB的优化，并结合 4.0 版本代码，详细阐述如何巧用 maxTimeMS 办事端超时，来避免办事端要求积压导致雪崩的情形。

背景

业务方在腾讯云MongoDB运营过程中，曾有业务集群出现过：慢要求 -> 客户端断开重试 -> 办事端累积的要求越来越多 -> 办事雪崩 -> 人工重启解决的问题。

过去，为了防止办事雪崩，腾讯云MongoDB应对的解决方案是：在内核中实现了连接状态检测、自适应限流等功能进行过载保护，并开发了外围工具 kill 长时间运行的要求等。但是过载保护本质上会进行办事降级，对业务还是会产生一定影响，而外围工具处理起来也不够及时，甚至可能在节点 hang 住时无法工作，以上解决举措都存在着一定程度的弊端。

为了更好地避免办事雪崩，腾讯云MongoDB建议设置办事端超时，并和客户端超时保持一致。这样在客户端出现超时后，办事端也立刻终止这些“无意义”要求的执行。通过避免办事端资源的无效占用，极大地降低客户端不断重试导致办事雪崩的概率。

MongoDB原生办事端超时原理

当一个用户要求到达 mongos 或者 mongod 时，会生成一个对应的 OperationContext 对象，来记录这个要求从开始到结束期间的完整上下文信息。上下文信息中就包含了后面要介绍的“时间信息”：起始时间，已执行时间，超时时间，以及是否是 kill 状态等。相关成员和接口如下图所示：

其中 checkForInterrupt() 接口的作用就是检测要求是否应该终止，需满足以下 3 个条件之一：

1.实例处于 shutdown 状态；

2.用户应用 killOp 饬令，调用 markKilled() 接口，将 OperationContext 标记为了终止状态；

3.用户通过 maxTimeMS 参数给 OperationContext 设置了超时 Deadline，然后检测到 hasDeadlineExpired() 为 true；

一个要求在执行过程中会多次调用 checkForInterrupt() 检测自己是否超时，比如在获取Global ticket，获取资源锁，yield，内部迭代重试等阶段会主动检测并超时退出。

备注1：原生 MongoDB 在 3.7.3 版本通过 SERVER-33473 （https://jira.mongodb.org/browse/SERVER-33473）才反对获取 Global Ticket 时能够主动超时和打断，因此更低版本在 qr/qw 较大，要求排队比较严重时无法及时超时退出；而且在 3.7.3 版本通过 SERVER-32638  （https://jira.mongodb.org/browse/SERVER-32638）才反对获取资源锁时主动超时，因此更低版本在获取互斥锁卡住时也无法及时超时退出。

因此，为了有更好的体验，强烈建议升级到 4.0 或更高版本。

备注2：终止OperationContext 和 kill 进程/线程行为不同。OperationContext 自己检测和主动退出的机制使得 killOp 和 maxTimeMS 不会绝对精确。从我们对 maxTimeMS 的测试来看，能够保证误差在 1 秒内，大部分在 10ms 级别。也就是说用户设置的 100ms 超时，在后台可能会执行 110ms 左右。

应用小贴士：

以常见的 CRUD 操作为例，用户在饬令参数中加上 maxTimeMS 的设置即可。

例如将以下操作的办事端超时设置为 100ms：

// 查询操作db.runCommand({find:"cmongo_test", filter:{a:1} , maxTimeMS: 100})// 插入操作db.runCommand({insert:"cmongo_test", documents: [{a:1}], maxTimeMS: 100})// 更新操作db.runCommand({update:"cmongo_test", updates:[{q:{a:1}, u:{$set:{b:3}}}], maxTimeMS: 100})// 删除操作db.runCommand({delete:"cmongo_test3", deletes: [{q : {a :1}, limit:1}], maxTimeMS: 100})

如果办事端超时，客户端会收到类似如下的错误（客户端还没超时断开的情况下）：

{ "ok" : 0, "errmsg" : "Encountered non-retryable error during query :: caused by :: operation exceeded time limit", "code" : 50, "codeName" : "MaxTimeMSExpired",}

MongoDB 原生版本问题

在腾讯云MongoDB运营过程中，发现原生版本有 2 个比较大的应用痛点：一是原生 5.0 以下版本，在分片集群模式下不反对insert/update/delete 写饬令的超时；二是缺乏办事端默许的 maxTimeMS 设置。

1.原生 5.0 以下版本，在分片集群模式下不反对 insert/update/delete 写饬令的超时

在 4.4 及以下版本中，mongos 在接收到写饬令时，会应用 maxTimeMS 设置要求的 OperationContext 超时，然后将写入的数据拆分成子要求发给 mongod. 但是 mongod 侧收到的子要求中已经没有了 maxTimeMS 参数，因此 mongod 侧不会主动超时。

所以用户在对 mongos 发起一个携带 maxTimeMS 的写饬令时，迟迟等不到超时报错。

以 4.0 版本为例，常用饬令对 maxTimeMS 的反对情况如下：

饬令

mongos

mongod

备注

find

反对   

反对

https://docs.mongodb.com/v4.0/reference/command/find/

getmore

反对

反对

https://docs.mongodb.com/v4.0/reference/command/getMore/

getMore 这里特指 awaitDataTimeOut 超时，即 cursor 等待有新数据的时间。 SERVER-34277 （https://jira.mongodb.org/browse/SERVER-34277）提议引入新字段进行区分，不过社区还没有做

findAndModify

反对

反对

https://docs.mongodb.com/v4.0/reference/command/findAndModify/

aggregate相关

aggregate/count/distinct

反对

反对

https://docs.mongodb.com/v4.0/reference/command/aggregate/

https://docs.mongodb.com/v4.0/reference/command/count/

https://docs.mongodb.com/v4.0/reference/command/distinct/

insert

  ×

反对

https://docs.mongodb.com/v4.0/reference/command/insert/

update

  ×

反对

https://docs.mongodb.com/v4.0/reference/command/update/

delete

  ×

反对

https://docs.mongodb.com/v4.0/reference/command/delete/

这个 Bug 直到 4.7.0 版本通过 SERVER-46187 （https://jira.mongodb.org/browse/SERVER-46187）才修复，并随着今年 5.0 版本的推出才解决。但是，5.0 新版本尝鲜的寥寥无几，绝大部分用户都在应用比较成熟的 4.0 / 4.2 / 4.4 版本。

2.缺乏办事端默许的 maxTimeMS 设置

MongoDB 的饬令和参数众多，普通用户很难注意并理解 maxTimeMS 的设置，即使想开启这个功能也需要修改代码并上线发布。而且如果多租户共享一个集群，怎么保证其他人也开启了默许超时也是一个问题。因此，整体应用体验上需要改进。

另外，和 maxTimeMS 参数对比，原生MongoDB 允许在办事端设置默许的 writeConcern 级别，并在最新发布的 5.0 版本中将默许设置调整为 majority ，防止新手用户不理解规则导致重要数据出现安全性问题。本质上来说，是通过办事端默许设置来降低用户的应用成本。

因此，腾讯云MongoDB作为一个注重用户体验的云数据库，认为有必要在办事端反对默许的 maxTimeMS 设置。

腾讯云MongoDB对 maxTimeMS 办事端超时的优化

1.完善 mongos 写饬令对 maxTimeMS 的反对

Mongos 会根据原始要求按目标 shard 分组之后重构子要求，并将每个子要求转发给对应的 shard。

下图展示一个写要求在mongos 上的执行路径，比较关键的点有：

在 runCommand 函数中，会从饬令中解析 maxTimeMS（客户指定的），并设置 OperationContext 的 deadline；

在BatchWriteExec::executeBatch 函数中，会重构子要求，加上 sessionId 和 transactionId 等信息，但是没有携带 maxTimeMS 信息；

这时会出现 2 个问题：

OperationContext 只能跟踪 1 个要求在 1 个进程中的执行信息，也就是说 mongos 和 mongod 各自有自己独立的 OperationContext。因此，虽然要求在 mongos 中有 deadline，但是 mongod 上没有；

子要求没有将 maxTimeMS 透传给 mongod，因此 mongod 侧也无法根据子要求信息设置 OperationContext 的 deadline；

解决方法：在生成子要求时，计算总要求当前还剩余多少执行时间，并作为 maxTimeMS 参数增加到子要求中，再透传给 mongod。

整体架构如下所示：

备注：社区 5.0 版本 SERVER-46187 （https://jira.mongodb.org/browse/SERVER-46187）的修复思路和腾讯云MongoDB的修复方法类似。

2.反对腾讯云MongoDB办事端默许设置

腾讯云MongoDB反对分片和副本集 2 种应用模式。

对于分片集群，可以通过 mongos 在 configSvr 的 config.cmongo_settings 中设置默许参数。mongos 在处理要求时，如果要求中携带了用户指定的 maxTimeMS 参数，则以用户指定的为准；如果用户没有指定，则增加默许设置。

整体架构如下图所示：

对于副本集集群，也是在副本集的 config.cmongo_settings 表中存储默许设置，如下图所示：

备注：默许设置只对用户要求生效，腾讯云MongoDB集群内部的行为。（比如主从同步，session 上下文信息持久化等要求不受影响）

应用小贴士

腾讯云MongoDB在 4.0 和 4.2 版本进行了上述优化。

对于需要应用 maxTimeMS 功能的用户，建议先将腾讯云MongoDB的小版本升级到最新，然后通过如下方式进行默许设置：

分片集群登陆 mongos， 副本集登陆 mongod；

设置 config.cmongo_settings 表（在 1 个 mongos 或者 mongod 节点上设置即可，其他 mongos 或者 mongod 节点会在 10 秒内自动同步设置）；

# 切换到 config DBuse config# 第 1 次设置db.cmongo_settings.insert({"_id" : "maxTimeMS", "value": 1000})# 设置变更db.cmongo_settings.update({"_id" : "maxTimeMS"} , {$set: {"value": 2000}})# 关闭设置db.cmongo_settings.update({"_id" : "maxTimeMS"} , {$set: {"value": 0}}

总结

本文通过对 MongoDB 办事端超时原理和原生版本存在的问题做了分析阐述。腾讯云MongoDB在原生版本的基础上，解决了 4.0 和 4.2 版本无法在 mongos 侧正确处理写饬令超时的问题，并反对了办事端的默许设置，保证办事端超时后能很快退出，防止后端要求积压导致办事雪崩，最终在功能正确性和用户体验上实现了相关优化目标。