writeConcern
db.collection.insert({x: 1}, {writeConcern: {w: 1}})
客户端在写入数据时，可以通过writeConcern来配置写入策略，其包含如下选项
- w：指定数据需要写入多少个节点才会向客户端返回确认，选项默认为1，即写到primary就OK了。
w:majority则表示需要写入副本集中大多数成员后才完成，提升了数据的写入安全，但会降低写入性能 - j：写入操作的journal持久化后才向客户端返回确认，默认为false
- wtimeout：写入超时时间，仅当w大于1时生效
MongoDB Replset复制是通过secondary节点不断拉取primary上的oplog并重放来实现的，那w:majority是如何确保写入到大多数的呢？
- 客户端发起写入请求，并记录到primary上的oplog中，等待从节点应用写入
- secondary拉取primary的oplog并重放
- secondary上的独立线程在oplog时间戳发生更新时，就会向primary发送replSetUpdatePosition命令更新自己的oplog时间戳
- 当primary发现足够多的节点oplog时间戳已经满足要求了，向客户端返回确认
readConcern
MongoDB V3.2引入了readConcern来配置读策略，该参数容易与readPreference混淆，两者并不冲突，区别如下：
-
readPreference控制客户端从副本集的哪个节点读取数据，用于实现读写分离、就近读取等功能。其包含如下选项：
- primary：默认配置，所有读请求全都发到primary节点上
- primaryPreferred：优先从primary读取，当primary无法响应时，从secondary读
- secondary：读请求全都转发到secondary
- secondaryPreferred：优先从secondary读取，当secondary无法响应时，从primary读取
- nearest：根据网络距离就近选择
-
readConcern决定读取数据时，能读到怎样的数据，其包含如下选项：
- local：能读取任意数据，默认选项
- majority：只能读取到"已写入大多数节点的数据"
readConcern设计用于解决脏读问题，例如客户端先在primary读取了一条数据，但该数据还未同步到大多数节点就因为primary down引起的Rollback，那客户端在新primary上无法读取到之前的数据，导致客户端发生了脏读。
需要注意区分的是readconcern并不保证读取到的数据是最新的，只是避免了Rollback导致的脏读问题，具体读取哪个节点的是由readPreference策略决定的
readConcern原理
配置readconcern:majority需要先确认replication.enableMajorityReadConcern参数已经开启。配置该参数后，MongoDB会单独起一个snapshot线程，定期采集数据集的快照，并记录快照对应的oplog时间戳，只有当oplog已经应用到大多数节点时，对应的snapshot才会标记为committed，用户读取就只能读取最后一个committed状态的快照数据。
关闭readconcern
由于readConcern的snapshot保存在内存中，增加了cache的消耗，对性能存在一定影响，如果需要关闭我们可以设置replication.enableMajorityReadConcern为false，并通过在mongod实例上执行db.serverStatus()查看storageEngine.supportsCommittedReads
关闭也会带来一定的影响，例如：
- MongoDB4.0及更早版本中，禁用readConcern:majority将会禁用change stream，V4.2开始则无影响
- 对分片集群事务也存在影响
- 禁用可以防止修改索引的collMod命令回滚
详细内容可参考Read Concern "majority"
