MongoDB写入数据策略 _MongoDB

上篇文章介绍了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创建单个日志记录，其中包含更新操作及其关联的索引修改。
【MongoDB写入数据策略】每个记录都有一个唯一的标识符。
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模式下，只需要写入两个数据节点即可返回，流程如下：