mongodb-事务
前言
写事务
使用 writeConcern 保证数据准确落盘
读事务
readPreference 来确定从哪里读
readConcern 来确定可以读什么样的数据
多文档事务
前言
事务是 mongoDB 中非常核心的一个功能，在 4.0 版本以前，mongoDB 只支持单个文档的事务，在 4.0 和 4.2 版本之后，分别支持了复制集事务和分片事务，也可以说在大多数的数据库中都是非常重要的一个功能，值得我们单独拉一章去讲解
那「怎么样在 mongoDB 中合理的使用事务来保证数据安全呢」？
后续我将会从读、写和多文档事务这三个方向去阐述
写事务
使用 writeConcern 保证数据准确落盘
writeConcern 中有两个选项
w（决定一条数据落到写到多少个节点才算真正成功） 0：不关心（最不安全） 数字：写到 n 个节点才算成功（自定义） majority：写入至少一半的节点才算成功（推荐，性能和安全均衡） all：全部写完才算成功（性能差点，很安全，但是只要有一个失败就会失败） j（决定怎样才算真正成功） true：写入 journal 日志 才算成功 false：写入内存就算成功
db.collection.insert({a:1},{writeConcen:{w:"majority",j:true});
对于一些「普通数据可以使用 w:1 来确保最佳性能」，对于「重要数据可以用 w:majority 来保证数据安全」
读事务
readPreference 来确定从哪里读
readPreference 有几个属性
primary：只从主节点读 primaryPreferred：先读主节点，如果挂了再读从节点 secondary：只从从节点读 secondaryPreferred：先读从节点，如果挂了在读主节点 nearest：读最近的节点
「primiry 和 primaryPreferred 适用于对延迟敏感读较高」的数据，比如订单信息
「secondary 和 secondaryPreferred 适用于对延迟敏感度要求较低」的数据，比如日志信息
「nearest 适用于业务域较广的应用」，比如将业务信息同步到全球各地的节点，「中国用户会访问中国的节点，俄罗斯用户会访问俄罗斯的节点」， nearest 的判断也是比较简单的，直接是使用应用到 mongo 服务器的的 ping time 来决定
当然，还有一种是给「服务器打标签(tag) 的方式」，比如要将读取操作定向到标记有 "name": "a"和"key": "person"的辅助节点集：
db.collection.find({}).readPref( "secondary", [ { "name": "a", "key": "person" } ] )
readConcern 来确定可以读什么样的数据
readConcern 有几个属性
available：读取所有可用的数据 loacl：读取所有可用且仅属于当前分片的数据 majority：读取大多数节点都写入的数据 「通过快照来维护多个不同的版本，使用 MVCC 实现」，每个被大多数节点确认过的数据就是一个快照 linearizable：可线性化读取文档 有时会被阻塞，其保证如果一个线程已经完成了写入并且告知了其他线程，那么这其他的线程就可以看到这些改动。如果某一瞬间你的副本集出现了两个主节点（有一个还未来得及降级）然后你从这个老的主节点上进行读取，与此同时新的主节点上已经有了新的数据，你读到的数据就是旧数据 snapshot：读取快照中的数据(类似于可串行化)
loacl 和 available 的区别体现在分片集群中的 chunk 迁移上，如果读 shard2 ，loacl 不能读到 x ，但是 available 可以读到
多文档事务
4.0 版本 mongoDB 支持了复制集的多文档事务
4.2 版本 mongoDB 支持了分片集群的多文档事务
也就是说是说，mongoDB 在 4.2 版本的是有拥有了和 mysql 这种关系型数据库一样的事务能力，这对于业务的选择角度来讲，又给 mongoDB 添加了一笔浓重的色彩
在整个数据库的分布式事务当中，还需要重点提一嘴的就是时间问题，我们先来看看会有什么问题存在
比如有两个操作发向 a、b 两个节点
客户端将 a = 1 发向 a、b 节点 a 节点操作 a =1 客户端将 a = a +1 发送给 a、b 节点 a 节点操作 a = a + 1 b 节点由于业务网络等原因先执行了 a = a + 1，后操作了 a = 1
最后我们就发现，a、b 两个节点的数据不一致了，那么 mongo 是怎么解决的呢，一般是两种方式：
「全局授时」；比如我们可以采用GPS时钟或者是NTP服务这种全局授时点
「逻辑时钟」：也就是我们采用一种局部的时间戳的方式去演进，这个就叫逻辑时钟。
mongo 采用的是「混合逻辑时钟」:
在这个混合逻辑时钟中，将物理时钟和逻辑时钟混合起来做一个全局的时间出来处理。我们的混合逻辑时钟会采用一种本地的推进方式，这个就是刚才说的一个接受的时候，他会比较本地的时间戳，然后在本地时间戳、本地真实的物理时间和收到最短 request 的时间，「三者取最大的时间，作为本地时间的一个推进」，需要说明的是，这个时间戳的分配是取决于 oplog 的时间戳。只有「当 oplog 真正写入数据的时候，本地的逻辑时钟才会向前推进」。在整个混合逻辑时钟，在整个集群中采用动态推进的方式，「每一条发送和接收的请求，都会依据请求中的时间来推进本地的时钟」，这样在全局的情况下，每个节点的混合逻辑时钟最终会趋同，趋向同一个地址，趋向同一个时间。这样的话，刚才说的时间偏差就已经不存在了，才可以在集群中做分布式事务。
再说说 mongo 提交事务的过程吧
mongoDb 的分布式事务和 mysql 一样，也是基于「两阶段协议」。
第一阶段就是 prepare 阶段，在 prepare 过程中，所有的 coordinator 会向所有的节点去发送 prepare 命令，所有的节点收到了这个命令以后会返回自己的 prepare timestamp，然后由协调节点去决定选取一个最大的 prepare ts 作为 commit timestamp。
coordinator 和所有的 shard 之间的通讯会促使所有的事务参与者得到一个协调一致的 HLC。在这种逻辑时钟一致的情况下，commit timestamp 就是全局顺序一致的。
第二阶段的话就是提交阶段， coordinator 会将刚刚的 committed ts 作为 commit timestamp 的时间戳，然后向所有的节点去广播。
需要关注一点，就是在对具有 prepare timestamp 的事务进行读取的时候，如果当前的事务是处于 prepare 状态的，并不确定自身的读时间戳和 prepare 状态的大小的话，需要去一直等待这个事务，等到事务提交或者 abort 以后才去会处理，这个就是刚才所说的。
https://mongoing.com/archives/77608
巨人的肩膀
mongoDB 整个事务实现的方式都是按照「读提交」这种关系来设计的，也就是说，在客户端读取数据的时候，只能读到该事务节点前已经做了 commit 的数据。