《MongoDB高手课》学习记录（第十八天）

第十八天

今天要学习的章节是《21 | 事务开发：读操作事务之二》，继续昨天的话题，昨天讲的是从哪读readPreference，今天讲的是要读什么样的数据readConcern。

什么是 readConcern？

在 readPreference 选择了指定的节点后，readConcern 决定这个节点上的数据哪些是可读的，类似于关系数据库的隔离级别。可选值包括：

• available：读取所有可用的数据;
• local：读取所有可用且属于当前分片的数据，这个是默认值;
• majority：读取在大多数节点上提交完成的数据;
• linearizable：可线性化读取文档;
• snapshot：读取最近快照中的数据，这个在第三章中讲;

readConcern: local 和 available

在复制集中 local 和 available 是没有区别的。两者的区别主要体现在分片集上。考虑以下场景：

• 一个 chunk x 正在从 shard1 向 shard2 迁移；
• 整个迁移过程中 chunk x 中的部分数据会在 shard1 和 shard2 中同时存在，但源分片 shard1仍然是chunk x 的负责方：
• 所有对 chunk x 的读写操作仍然进入 shard1；
• config 中记录的信息 chunk x 仍然属于 shard1；
• 此时如果读 shard2，则会体现出 local 和 available 的区别：
• local：只取应该由 shard2 负责的数据（不包括 x）；
• available：shard2 上有什么就读什么（包括 x）；

readConcern: local 和 available

注意事项：

• 虽然看上去总是应该选择 local，但毕竟对结果集进行过滤会造成额外消耗。在一些无关紧要的场景（例如统计）下，也可以考虑 available；
• MongoDB <=3.6 不支持对从节点使用 {readConcern: "local"}；
• 从主节点读取数据时默认 readConcern 是 local，从从节点读取数据时默认readConcern 是 available（向前兼容原因）。

readConcern: majority

说白了，就是超过一半的节点数据提交成功，才会读取出

readConcern: majority 的实现方式

考虑 t3 时刻的 Secondary1，此时：

• 对于要求 majority 的读操作，它将返回 x=0；
• 对于不要求 majority 的读操作，它将返回 x=1；

如何实现？
节点上维护多个 x 版本，MVCC 机制
MongoDB 通过维护多个快照来链接不同的版本：

• 每个被大多数节点确认过的版本都将是一个快照；
• 快照持续到没有人使用为止才被删除；

实验： readConcern : ”majority” vs “local”

• 安装 3 节点复制集。
• 注意配置文件内 server 参数 enableMajorityReadConcern

• 将复制集中的两个从节点使用 db.fsyncLock() 锁住写入（模拟同步延迟）

readConcern 验证

• db.test.save({“A”:1})
• db.test.find().readConcern(“local”)
• db.test.find().readConcern(“majority”)
• 在某一个从节点上执行 db.fsyncUnlock()
• 结论：
• 使用 local 参数，则可以直接查询到写入数据
• 使用 majority，只能查询到已经被多数节点确认过的数据
• update 与 remove 与上同理

readConcern: majority 与脏读

这个其实就和oracle的事务一个样
MongoDB 中的回滚：

• 写操作到达大多数节点之前都是不安全的，一旦主节点崩溃，而从节还没复制到该次操作，刚才的写操作就丢失了；
• 把一次写操作视为一个事务，从事务的角度，可以认为事务被回滚了。

所以从分布式系统的角度来看，事务的提交被提升到了分布式集群的多个节点级别的“提交”，而不再是单个节点上的“提交”。
在可能发生回滚的前提下考虑脏读问题：

• 如果在一次写操作到达大多数节点前读取了这个写操作，然后因为系统故障该操作回滚了，则发生了脏读问题；

使用 {readConcern: “majority”} 可以有效避免脏读

readConcern: 如何实现安全的读写分离

考虑如下场景：

向主节点写入一条数据；
立即从从节点读取这条数据。

如何保证自己能够读到刚刚写入的数据？

下述方式有可能读不到刚写入的订单

db.orders.insert({ oid: 101, sku: ”kite", q: 1})
db.orders.find({oid:101}).readPref("secondary")

使用 writeConcern + readConcern majority 来解决

db.orders.insert({ oid: 101, sku: "kiteboar", q: 1}, {writeConcern:{w: "majority”}})
db.orders.find({oid:101}).readPref(“secondary”).readConcern("majority")

readConcern: linearizable

只读取大多数节点确认过的数据。和 majority 最大差别是保证绝对的操作线性顺序，在写操作自然时间后面的发生的读，一定可以读到之前的写

• 只对读取单个文档时有效；
• 可能导致非常慢的读，因此总是建议配合使用 maxTimeMS；

readConcern: snapshot

{readConcern: “snapshot”} 只在多文档事务中生效。将一个事务的 readConcern
设置为 snapshot，将保证在事务中的读：

• 不出现脏读；
• 不出现不可重复读；
• 不出现幻读。

因为所有的读都将使用同一个快照，直到事务提交为止该快照才被释放。

readConcern: 小结

• available：读取所有可用的数据
• local：读取所有可用且属于当前分片的数据，默认设置
• majority：数据读一致性的充分保证，可能你最需要关注的
• linearizable：增强处理 majority 情况下主节点失联时候的例外情况
• snapshot：最高隔离级别，接近于 Seriazable