MongoDB Wire Protocol是一个简单的基于套接字的请求-响应样式协议。客户端通过常规的TCP / IP套接字与数据库服务器通信。
消息有两种类型:客户端请求和数据库响应。
通常,每个消息都由一个标准消息头和随后的请求特定数据组成。标准消息头的结构如下:
领域 | 描述 |
---|---|
messageLength |
消息的总大小(以字节为单位)。该总数包括保存消息长度的4个字节。 |
requestID |
客户端或数据库生成的标识符,用于唯一标识此消息。对于客户端生成的消息(例如OP_QUERY和
OP_GET_MORE),它将responseTo 在OP_REPLY
消息的字段中返回。客户可以使用requestID 和
responseTo 字段将查询响应与原始查询相关联。 |
responseTo |
对于来自数据库的消息,将
requestID 取自客户端的OP_QUERY或
OP_GET_MORE消息。客户可以使用requestID 和responseTo 字段将查询响应与原始查询相关联。 |
opCode |
消息类型。有关详细信息,请参见请求操作码。 |
注意
与MongoDB的2.6启动和,MongoDB的驱动程序使用的数据库命令,和
代替,和用于确认写入。大多数驱动程序继续使用操作码进行未确认的写入。maxWireVersion
3
insert
update
delete
OP_INSERT
OP_UPDATE
OP_DELETE
在4.2版中,MongoDB删除了不赞成使用的内部OP_COMMAND
和
OP_COMMANDREPLY
协议。
以下是受支持的opCode
:
操作码名称 | 值 | 评论 |
---|---|---|
OP_REPLY |
1个 | 回复客户请求。responseTo 被设置。 |
OP_UPDATE |
2001 | 更新文件。 |
OP_INSERT |
2002年 | 插入新文件。 |
RESERVED |
2003年 | 以前用于OP_GET_BY_OID。 |
OP_QUERY |
2004年 | 查询集合。 |
OP_GET_MORE |
2005年 | 从查询中获取更多数据。请参见游标。 |
OP_DELETE |
2006年 | 删除文件。 |
OP_KILL_CURSORS |
2007年 | 通知数据库客户端已完成游标。 |
OP_MSG |
2013年 | 使用MongoDB 3.6中引入的格式发送消息。 |
客户端可以发送指定除OP_REPLY操作码之外的所有请求消息 。OP_REPLY 保留供数据库使用。
只有OP_QUERY和 OP_GET_MORE消息会导致来自数据库的响应。对于其他任何消息,将不会发送任何响应。
您可以使用getLastError命令确定消息是否成功。
OP_UPDATE消息用于更新集合中的文档。OP_UPDATE消息的格式如下:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
ZERO |
整数值0。保留以备将来使用。 |
fullCollectionName |
完整的收藏名称;即名称空间。完整集合名称是数据库名称与集合名称. 的串联,并使用a 表示串联。例如,对于数据库foo 和集合bar ,完整的集合名称为foo.bar 。 |
flags |
位向量,用于指定操作标志。这些位值对应于以下内容:
|
selector |
BSON文档,用于指定查询以选择要更新的文档。 |
update |
BSON文档,指定要执行的更新。有关指定更新的信息,请参阅《 MongoDB手册》中的“ 更新操作”文档。 |
对OP_UPDATE消息无响应。
OP_INSERT消息用于将一个或多个文档插入到集合中。OP_INSERT消息的格式为
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
flags |
位向量,用于指定操作标志。这些位值对应于以下内容:
|
fullCollectionName |
完整的收藏名称;即名称空间。完整集合名称是数据库名称与集合名称. 的串联,并使用a 表示串联。例如,对于数据库foo 和集合bar ,完整的集合名称为foo.bar 。 |
documents |
一个或多个要插入集合的文档。如果有多个,则依次将它们依次写入套接字。 |
对OP_INSERT消息无响应。
OP_QUERY消息用于在数据库中查询集合中的文档。OP_QUERY消息的格式为:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
flags |
位向量,用于指定操作标志。这些位值对应于以下内容:
|
fullCollectionName |
完整的收藏名称;即名称空间。完整集合名称是数据库名称与集合名称. 的串联,并使用a 表示串联。例如,对于数据库foo 和集合bar ,完整的集合名称为foo.bar 。 |
numberToSkip |
设置要省略的文档数-从结果数据集中的第一个文档开始-返回查询结果时。 |
numberToReturn |
将第一个OP_REPLY消息中的文档数限制为查询。但是,cursorID 如果结果多于,数据库仍将建立游标并将其返回给客户端numberToReturn 。如果客户端驱动程序提供了“限制”功能(例如SQL LIMIT关键字),则由客户端驱动程序来确保将不超过指定数量的文档返回给调用应用程序。如果numberToReturn 为0 ,则数据库将使用默认的返回大小。如果数字为负,则数据库将返回该数字并关闭游标。无法获取该查询的其他结果。如果numberToReturn 为,
1 则服务器会将其视为-1 (自动关闭光标)。 |
query |
代表查询的BSON文档。该查询将包含一个或多个元素,所有这些元素都必须匹配才能将文档包含在结果集中。可能的因素包括
$query ,$orderby ,$hint ,和$explain 。 |
returnFieldsSelector |
可选的。BSON文档,用于限制返回文档中的字段。所述 |
数据库将使用OP_REPLY消息响应 OP_QUERY消息。
OP_GET_MORE消息用于在数据库中查询集合中的文档。OP_GET_MORE消息的格式为:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
ZERO |
整数值0。保留以备将来使用。 |
fullCollectionName |
完整的收藏名称;即名称空间。完整集合名称是数据库名称与集合名称. 的串联,并使用a 表示串联。例如,对于数据库foo 和集合bar ,完整的集合名称为foo.bar 。 |
numberToReturn |
将第一个OP_REPLY消息中的文档数限制为查询。但是,cursorID 如果结果多于,数据库仍将建立游标并将其返回给客户端numberToReturn 。如果客户端驱动程序提供了“限制”功能(例如SQL LIMIT关键字),则由客户端驱动程序来确保将不超过指定数量的文档返回给调用应用程序。如果numberToReturn 为0 ,则数据库将使用默认的返回大小。 |
cursorID |
OP_REPLY中的光标标识符。这必须是来自数据库的值。 |
数据库将使用OP_REPLY消息响应 OP_GET_MORE消息。
OP_DELETE消息用于从集合中删除一个或多个文档。OP_DELETE消息的格式为:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
ZERO |
整数值0。保留以备将来使用。 |
fullCollectionName |
完整的收藏名称;即名称空间。完整集合名称是数据库名称与集合名称. 的串联,并使用a 表示串联。例如,对于数据库foo 和集合bar ,完整的集合名称为foo.bar 。 |
flags |
位向量,用于指定操作标志。这些位值对应于以下内容:
|
selector |
BSON文档,代表用于选择要删除的文档的查询。选择器将包含一个或多个元素,所有这些元素都必须匹配才能将文档从集合中删除。 |
对OP_DELETE消息无响应。
OP_KILL_CURSORS消息用于关闭数据库中的活动游标。这是确保在查询结束时回收数据库资源所必需的。OP_KILL_CURSORS消息的格式为:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
ZERO |
整数值0。保留以备将来使用。 |
numberOfCursorIDs |
消息中的游标ID的数量。 |
cursorIDs |
要关闭的游标ID的“数组”。如果有多个,则依次将它们依次写入套接字。 |
如果游标被读取直到用尽(直到OP_QUERY 或OP_GET_MORE返回零作为游标ID 为止),就没有必要终止游标。
MongoDB版本中的新功能: 3.6
OP_MSG
是一种可扩展的消息格式,旨在包含其他操作码的功能。此操作码具有以下格式:
领域 | 描述 |
---|---|
header |
标准消息头,在如所描述的标准消息头。 |
flagBits |
包含消息标志的整数位掩码,如 标志位中所述。 |
sections |
消息主体部中,如所描述的章节。 |
checksum |
可选的CRC-32C校验和,如 Checksum中所述。 |
该flagBits
整数是编码修改的格式和行为的标志位掩码OP_MSG
。
前16位(0-15)是必需的, 如果设置了未知位,则解析器务必出错。
最后16位(16-31)是可选的,解析器务必 忽略任何未知的置1位。代理和其他消息转发器 必须在转发消息之前清除所有未知的可选位。
位 | 名称 | 请求 | 响应 | 描述 |
---|---|---|---|---|
0 | checksumPresent |
✓ | ✓ | 该消息以包含CRC-32C [1] 校验和的4个字节结尾。有关详细信息,请参见校验和。 |
1个 | moreToCome |
✓ | ✓ | 另一条消息将跟随此消息,而无需接收者采取进一步措施。接收器必须不发送另一消息,直到接收到一个具有moreToCome 设置为0作为发送可能阻塞,引起死锁。moreToCome
设置了该位的请求将不会收到回复。答复将仅在设置了该exhaustAllowed 位的情况下响应此请求。 |
16 | exhaustAllowed |
✓ | 客户端已准备好使用该 这样可以确保仅在请求者的网络层已准备好多个答复时才发送它们。 重要 MongoDB 3.6会忽略此标志,并将以一条消息进行响应。 |
一条OP_MSG
消息包含一个或多个部分。每个部分都以一个kind
指示其类型的字节开头。kind
字节之后的所有内容均构成该节的有效负载。
可用的部分如下。
类型 | 描述 |
---|---|
int32 | 节的大小(以字节为单位)。 |
C字串 | 文档序列标识符。在所有当前命令中,此字段是从正文部分替换的(可能是嵌套的)字段。 此栏不得也存在于主体部分。 |
零个或多个BSON对象 |
|
该OP_REPLY
消息由数据库发送,以响应
OP_QUERY或OP_GET_MORE消息。OP_REPLY消息的格式为:
领域 | 描述 |
---|---|
header |
消息标头,如标准消息标头中所述。 |
responseFlags |
指定标志的位向量。这些位值对应于以下内容:
|
cursorID |
该cursorID OP_REPLY的一部分。如果查询的结果集适合一个OP_REPLY消息,cursorID 则该值为
0。cursorID 必须在用于获取更多数据的任何
OP_GET_MORE消息中使用此值,并且当不再需要通过OP_KILL_CURSORS
消息将其关闭时,客户端也必须将其关闭。 |
startingFrom |
光标的起始位置。 |
numberReturned |
回复中的文档数。 |
documents |
退回的文件。 |
脚注
[1] | (1,2)的32位CRC与Castagnoli酒店多项式计算如由https://tools.ietf.org/html/rfc4960#page-140。 |