上篇文章介绍了 Mongo 读取数据的策略（MongoDB 读数据策略），主要是 readconcern、readpreference 两参数，其中 readconcern 作用于服务端，决定了什么时候能读取到数据；readpreference 在客户端配置，决定读哪个节点的数据。本文将要介绍 Mongo 的写入策略，在介绍写入策略前，先简单说明 MongoDB 的 Journaling 特性。

Journaling 介绍

MongoDB 也有防 carsh 能力，和 MySQL 类似，也是通过预先写日志(WAL)到文件实现，这文件就是 Journaling 功能。

To provide durability in the event of a failure, MongoDB uses write ahead logging to on-disk journal files.

日志文件

开启 Journaling 功能后，Mongo 会在数据库目录下创建 journal 目录，用来存放 journal 日志，以 WiredTiger 引擎为例，文件格式是 WiredTigerLog.<sequence>，其中<sequence>是从 0000000001 开始的零填充数字。journal 日志文件默认大小为 100 MB，超过该限制后，将创建一个新的日记文件，并会自动删除旧的日志文件，仅保留从上一个检查点恢复所需的文件。所以 journal 日志文件一般情况下只会生成两三个，除非每秒有大量的写操作发生。

日志记录

journal 记录有这几个特点：

• 它包括由初始写入引起的任何内部写入操作。例如，对集合中文档的更新可能会导致对索引的修改；WiredTiger 创建单个日志记录，其中包含更新操作及其关联的索引修改。

• 每个记录都有一个唯一的标识符。

• WiredTiger 的最小日志记录大小为 128 字节。

另外，为了提高存储效率，MongoDB 牺牲了一些 CPU 性能，对 WiredTiger 引擎对日志数据使用压缩存储，默认压缩方式是 snappy 压缩，也支持其他压缩方式，比如：zstd、zlib 等，可以通过下面方式设置。

storage.wiredTiger.engineConfig.journalCompressor

总之，Journaling 是 MongoDB 中非常重要的一项功能，类似于关系数据库中的事务日志。Journaling 能够使 MongoDB 由于意外故障后快速恢复。在 2.0 版本后，默认开启了该功能。和 MySQL 一样，Mongo 实例启动时会检查 journal 日志文件，确认是否有需要恢复的数据。不过由于提交 journal 日志会产生写入阻塞，所以它对写入的操作有性能影响，但在生产环境中通常还是开启 Journaling 的。

数据写入策略

writeconcern 是 Mongo 针对写操作的参数，表示写请求对 mongod 实例的确认级别，决定数据的持久性。它可以用下面三个选项表示。

{ w: <value>, j: <boolean>, wtimeout: <number> }

writeconcern 选项

w 指定写操作需要应用到多少个数据节点才能返回成功，可以为 0、1、2、3 或者 majority。

w: 0 表示客户端不需要收到任何有关写操作，就直接返回成功。

w: 1 表示写主成功，就直接返回成功。

w: majority 需要收到多数节点（含主节点）关于操作执行成功的确认，具体个数根据复制集配置自动得出。比如，一主两从 3 节点的集群，则需要 2 个节点确认写入成功即可。

w: N（N > 1）表示 N 个数据节点确认才返回成功。

w 值越大，对客户端来说，数据的安全性保证越强，同时写操作的延迟越大。

w 设置的节点数越多，等待的延迟也就越大。如果 w 等于总节点数，那么一旦其中某个节点出现故障就会导致整个写入失败，这也是有风险的。另外，针对 Hidden、delayed 和 priority 为 0 的数据节点，官方也特别做了说明，如下：

NOTE

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

注意：

a、副本集中 Hidden、delayed 和 priority 为 0 的成员，可以确认 w: <number>的写操作。

b、延迟节点的返回写 ack，不会早于配置的 slavedelay 值 。

如果集群有 3 三个数据节点，在 w: majority 模式下 ，只需要写入两个数据节点即可返回，流程如下：

j 表示写操作是否要被持久化，只能选填 true 或 false。

• j:false 表示写操作到 cache 即算作成功。

• j:true 表示写操作到文件中才算成功。

从 3.2 版本后，如果指定 j:true，即使 w:0 ，只有在请求的成员数(包括主成员)写入日志后才返回数据。因此，j:true 设置保证了 MongoDB 的数据持久化。

Changed in version 3.2: With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal.

另外，仅仅 j:true 不保证集群 failover 时发生回滚的写操作。

j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover.

wtimeout：返回确认的超时时间，单位为毫秒。

如果写入操作超过该值，则返回错误，即使最终写入是成功了，但数据库不会撤销超时写入的数据。如果没有指定 wtimeout 值，则写入操作将无限期阻塞，wtimeout:0 等同于该选项未设置值。同时，这个参数和 WriteConncern 的 w 值有关，并且只适用于 w 大于 0 的情况。比如：w:0，表示可以超时无限大，则不返回错误；w:1，只和主节点确认的超时时间；w:majority，表示需要和多数节点确认超时时间。

数据提交策略

MongoDB 也有和 MySQL 有类似的提交策略，是由 commitIntervalMs 参数控制，它是日志持久化的间隔时间(以毫秒为单位)。如果想要更好的数据安全，可以设为每毫秒对 cache 中的数据做硬盘层面的 sync；如果需要更好的写入性能，最大可以改为每 500 毫秒做一次 sync。它的取值范围是 1 ~ 500 毫秒，默认值是 100 毫秒，不支持 in-memory 存储引擎。

总结

MongoDB 写入策略包括以下几个方面：

• w：指定写入数据后需要在多少个节点上同步写入成功后，才返回确认信息。

• j：设置 j:true 会将数据写入日志中，可以在节点宕机时恢复数据。但是 j:true 并不保证数据已经写入磁盘文件中。

wtimeout：指定写入超时时间。当写入操作达到超时时间时，即使最终成功写

入也会返回错误信息。

在实际使用中，可以根据具体的业务需求和系统环境来选择适合的写入策略，以达到最佳的性能和可靠性。例如，在数据一致性要求高的场景中，可以使用 majority 写入确认来保证数据同步的可靠性。而在性能要求高、数据不敏感的场景中，可以使用 w 值较小的写入关注点来提高写入性能。

NineData 即将会支持 MongoDB

本文作者是 NineData 工程师。NineData 向企业和个人提供高效、安全的数据库 SQL 开发、数据库备份、数据复制/迁移/集成、数据对比等能力的产品，它是开箱即用的 SaaS 服务，可以快速提升企业 SQL 开发效率，保障企业数据安全。近期，NineData 即将会支持 MongoDB、Redis 等 NoSQL 数据库。NineData 官网地址：https://ninedata.cloud。