PHP客户端与MongoDB通信协议

MongoDB 的 PHP 客户端有一个 MongoCursor 类，它是用于获取一次查询结果集的句柄（或者叫游标），这个简单的取数据操作，内部实现其实不是那么简单。本文就通过对 MongoCursor 类一些操作进行分析，向大家揭开 MongoDB 客户端服务器通信的一些内部细节。

通常来说，每一次find操作都会返回一个MongoCursor对象，在这个对象上调用getNext方法，就能够获得一条结果数据。循环调用getNext方法就能获取多条数据。下面我们就来看看其内部取数据的具体逻辑。

首先我们用最简单的方法来生成一个MongoCursor对象：

当我们调用 find 方法的时候，会生成一个 MongoCursor 对象，而这时候只是生成一个内存中的对象而已，并不会把我们的 find 查询发送到服务端，因为在生成 MongoCursor 对象后，我们还可能对它做一些其它操作，比如 sort，limit 等等。这就对查询条件进行了改变。

那什么时候 PHP 会对 MongoDB 发起 find 的网络请求呢，是在 MongoCursor 调用 getNext 方法的时候。比如我们在上面代码的基础上，再执行 sort 和 getNext 两个方法：

这时候第二行代码就会触发 find 的网络请求，具体请求的内容如下图，下图是对这次请求的二进制协议进行解析后的数据结构展示：

从上面图中我们可以看到，Number to Return 字段是0，MongoDB 协议里0表示不做限制，获取全部数据。所以这一次的 find 操作会把所有这个 collection 中的所有数据都拿到。而我们调用一次 getNext 实际上只拿到一条数据。那是不是说我们每调一次 getNext，PHP 就会进行一次网络请求获取一条数据呢？结果当然是否定的，这样效率未免也太低了。那好，那是不是 PHP 在第一次调用 getNext 就把所有数据拿回来，存在内存中，然后后续的 getNext 调用都在本地内存里取就行了呢？结果还是否定的，这样数据量大点 PHP 就容易被暴菊了吧。

所以事实上是怎么做的呢？我们来看下面一张图：

图上的 Number Returned 的值是101，也就是说 MongoDB 给我们返回了101条数据，这个101实际上就是服务器默认的 batchSize 大小。也就是说在没有指定返回多少条的情况下，会默认返回101条数据。这101条数据会存在 PHP 的内存中，这样后续的100次 getNext 调用，都不会再进行网络请求，而是直接从内存中返回数据。

如果我们在上面的 getNext 后再进行下面的调用。

上面先循环调用了100次 getNext，内存中的101项数据就都已经被取光了，然后当我们再次调用 getNext 去获取第102条数据的时候，PHP 内存中已经没有数据可以提供了，这时候又会再发起一次向 MongoDB 服务器的请求，去获取更多的数据。客户端这次会发起如下请求：

这次我们看到，请求的码变成了 Get More。也就是在上次的基础上获取更多数据。这时候实际 MongoDB 不会再按一个特定的条数返回数据，而是按一个特定的大小，目前是4M，也就是说，这一次，MongoDB 会返回最多4M的数据。对上面的请求，MongoDB 的返回如下：

这次返回结果中，标识了是从第101条开始，共返回了34673条数据。大小是4194378，正好是4M。

上面我们说了，MongoDB 默认的 batchSize 是101条，这个条数实际上我们可以通过客户端来设定的。在 PHP 中，通过 batchSize 函数来进行设置。比如我们用下面命令设定 batchSize 为25：

上面代码调用了一次 getNext，按上面讲到的，会一次性批量取N条数据回客户端。上面代码运行时产生的网络请求如下：

我们可以看到，Number to Return被设置为了25。

如果我们再循环执行getNext函数25次，加上上面代码一共执行26次，那么因为第一次只返回了25条记录，所以第26次调用getNext函数时会再一次触发网络请求。请求体如下：

由于我们设定了 batchSize 为25，所以这一次要求返回的也只有25条。服务端返回的数据也就只有25条。

除了 batchSize 函数以外，还有一个方法可以控制每次网络请求批量返回的记录条数，那就是在 MongoCursor 上调用 limit 函数，直接设置需要获取的记录条数。

比如下面代码，我们通过设置 limit 查询前50000条记录：

上面代码会发出下面的请求

我们看到，要求返回的数目是50000条，那么MongoDB服务器是不是就乖乖返回50000条数据了呢。让我们直接来看一下具体的返回数据包

很遗憾，MongoDB 服务端只返回了34678条，而不是我们理想中的50000条，其实原因也很简单，从 Message Length 的值就能看出来，因为目前请求包已经达到4M大小了，这个上限无法逾越。所以只能返回34678条数据了。

而同时，客户端在收到返回的数据包时，发现只有34678条数据，不够自己要求的50000条，还差 50000 ? 34678 = 15322 条，所以会再发起一次请求，要求服务器返回剩余的15322条记录。如下：

有时候我们可能会需要取很多条数据，比如上面的，通过设置limit为50000来获取50000条数据，而取这50000条数据的获取可能会超出 我们设置的 MongoCursor 的 timeout 限制，抛出 Cursor 超时的异常。这时候我们可以在设置 limit 的同时，设置 batchSize 来控制每两次请求服务器的时间间隔。以免由于获取大量数据导致的 MongoCursor 超时。

比如下面的例子里，我们要获取128条数据，但是通过设置 batchSize 来控制每次只从服务器取回50条。这样在后续的 getNext 调用中，就会发生三次网络请求，分别请求数目是50条，50条，28条。

上面我们说了通过设置 batchSiz e来控制客户端与 MongoDB 服务器的数据交换。但是这里有一个特例，当 batchSize 被设置为1，或者是负数时，MongoDB 只会返回第一次请求的数据包，然后直接关闭掉这个连接。也就是说，如果我们执行下面的命令：

会发现最后一个 var_dump 打出来的总是 NULL。因为每一次按 batchSize 的设置只返回了1条数据，然后连接就关闭了。

而我们只需要稍做修改，将 batchSize 改成2，情况就大为不同

可以看到，虽然第一次网络返回包被设置只返回两条数据，但是每三次调 getNext 时还是返回数据了，也就是说还是从服务器第二次获取到数据了。

实际上，通过上面的实验结果，我们已经大致对 MongoDB 客户端服务器通信协议有了大致的了解，更详细的内容我们可以直接在 MongoDB 官方文档中找到（Mongo Wire Protocal）