MongoDB事务的理解和思考

3.2版本开始引入Read Concern，解决了脏读，支持Read Commit
3.6版本引入Session，支持多个请求共享上下文，为后续的事务支持做准备
4.0支持多行事务，但4.0的事务只是个过渡的版本
4.2开始支持多文档事务

1. Mongo的架构

复制集架构

这是最基本的分布式架构，有一个主节点和两个节点。

主节点一般负责写入的功能。用户往主节点中写入数据时，主节点会更新数据表，并将操作信息生成一条oplog，写入到日志文件中。用户可以通过指定writeConcern来控制写入的行为。

从节点一般都只提供读功能，可以用于读写分离。从节点会定时轮询读取 oplog 日志，根据日志内容同步更新数据表，保持与主节点一致。更新完成后，在返回更新时间戳给到主节点。

2. Mongo事务

五种一致性级别

一致性级别	语义
local	从本地读取最新数据，但不保证该数据已被写入大多数副本集成员。数据可能会被回滚
available	从本地读取最新数据，但不保证该数据已被写入大多数副本集成员。数据可能会被回滚
majority	读取已经write majority 的数据。保证数据不会被回滚，但是不一定是本地的最新数据
linearizable	读取已经write majority的数据，但会等待在读之前所有的write majarity确认
snapshot	与关系型数据库中的快照隔离级别语义一致

2.1. write concern

要了解一致性，首先要了解数据是怎么写入的。MongoDB的write concern包含下面3个参数：

参数	含义	取值
w	写操作需要复制并应用到多少个副本集成员才能返回成功	0:不关心成功，立即返回 1:写主成功则返回 majarity:写大多数成功，才返回。比如3个节点中，写2个成功
j	写操作对应的修改是否要被持久化到存储引擎日志中	true or false
wtitmeout	主节点等待足够数量节点确认的超时时间，跟w有关，比如：w是1，则是带主节点确认的超时时间	单位:ms

写流程

先看一下主从同步的写流程图。

appliedOpTime：从节点上 Apply 完一批 Oplog 后，最新的 Oplog Entry 的时间戳。
durableOpTime：从节点上 Apply 完成并在 Disk 上持久化的 Oplog Entry 最新的时间戳

开启 WiredTiger 引擎层的一个事务，这个事务在提交时会顺便记录本次写操作对应的 Oplog
Entry 的时间戳
执行 ReplicationCoordinatorImpl::_awaitReplication_inlock 阻塞在一个条件变量，等待N个从节点完成
被阻塞的用户线程会被加入到 _replicationWaiterList 中，从节点完成后，唤醒该线程
从节点会不断从主节点上拉取oplog，在执行完后会更新自己的点位信息，同时还会有另一个后台进程，向主节点不断的汇报当前从节点的appliedOpTime 和 durableOpTime。
主节点的唤醒逻辑中，维护着一个lastOptime，如果 j 为false，则取从节点的appliedOpTime，否则就取durableOpTime
如果从节点的opTime，大于或者等于主节点的opTime，则认为从节点已经Apply完成
等待有N个从节点满足条件，则唤醒用户线程。

详细的主从同步原理参考：MongoDB复制集同步原理解析-阿里云开发者社区

从上面的流程可以知道，Mongo的复制是一个异步的过程。不同的节点之间，复制的进度是一样的。在一个从节点上的最新数据，在另一个从节点上，可能就不是最新的了。为此mongo也提供了local 等其他level来满足各种场景的读需求。

2.2. read concern

mongo的read concern 相比 write concern的实现要复杂的多的。

2.2.1. 快照

在介绍各个level的实现时，先来连接一下mongo中的快照。WiredTiger 为了保证并发事务在执行时，不同事务的读写不会互相 block，提升事务执行性能。采用的是类似PostgreSQL的MVCC的多版本控制方式。而不是像MySQL那样，用回滚段来保存数据。
与Oracle数据库和MySQL中的innodb引擎相比较，PostgreSQL、MongoDB的MVCC实现方式的优缺点如下。

优点：

事务回滚可以立即完成，无论事务进行了多少操作；
数据可以进行高频更新，不必像Oracle和MySQL的Innodb引擎那样需要经常保证回滚段不会被用完，也不会像oracle数据库那样经常遇到“ORA-1555”错误的困扰；

缺点：

旧版本数据需要清理。PostgreSQL清理旧版本的命令成为Vacuum，MongoDB中则由WiredTiger引擎负责清理；

ORA-1555错误：
产生ORA-01555错误的根本原因是由于UNDO块被覆盖，查询语句不能获取到查询语句发起时刻所构造的数据副本。

2.2.2. 快照的版本号管理

在MongoDB中，Server层用oplog时间戳来标识的顺序，但在WiredTiger中，是用事务ID（基于 Internal Transaction ID）来标识顺序。这两者在实现上毫无关联。在并发的场景下，这会导致Server层提交事务顺序和实际实施的事务顺序不一致。举个例子，Client A像Server层并发提交了两个事务T1和T2，在Server层看到的顺序是，T1先于T2。但在WiredTiger层，实际执行的可能是T2先于T1。

为了解决Server层和WiredTiger的顺序不一致的问题，Mongo引入了事务时间戳机制。Server层可以通过WT_SESSION::timestamp_transaction显式的为WiredTiger的事务指定一个时间戳（commit_ts）。有了这个时间戳，就能实现read as of a timestamp（指定时间戳读）特性。同时，WiredTiger引擎会维护一个majority committed 数据视图，也就是快照。每个快照的commit_ts时间戳被称为majority committed point，简称mcp。

2.2.3. 快照的内存管理

在MongoDB的4.2版本中，多版本的数据还是会存放在cache’中的。如果cache中一些旧的数据不及时清理，就会导致cache被耗光，从而降低性能。为此，WiredTiger提供了一个set_timestamp()函数来让Server层设置自己的Application Timestamp。

这里面时间戳有很多个，这里不展开。作用的话，看描述就能了解个大概了。先来看两个比较重要。

oldest
前面提到，Wired Tiger的多版本数据是在cache中维护的，且每个版本跟一个时间戳关联。cache中不能一直保留所有版本的数据，这会撑爆cache。为此WiredTiger 提供设置 oldest timestamp 的功能，并允许由 Server层设置该时间戳，来标哪些版本数据是没必要保存在内存中（也就是即使丢弃了，影响读取的一致性）。但这就意味这，Server 层需要频繁（及时）更新 oldest timestamp ，避免让 WT cache 压力太大。
从oldest timestamp的描述中，可以看出，WiredTiger引擎中不会缓存oldest timestamp之前的所有版本，比如活跃事务对应的版本数据，还是要保存的。
stable
表示该时间戳之前的数据都不会被回滚。stable timestamp 对应的快照被存储引擎持久化后，称之为 stable checkpoint
在3.x版本里，MongoDB的回滚，主要是通过不断的回滚oplog来实现的，但这种回滚的效率很慢。4.0通过引入stable checkpoint，可以通过调用接口，将数据回滚到某一个checkpoint。Server层在数据同步到大多数节点（majarity write），才会更新stable timestamp，而且stable timestamp 之前的数据代表是可以写到checkpoint，之后的则不会，所以这些数据是不会被回滚的。
同样的，Server层必须频繁的更新stable timestamp，否则就会影响WiredTiger的checkpoint行为，甚至会导致cache不够用。
pinned
当前 WiredTiger 收到新的 oldest timestamp 时，会取oldest_reader（当前的最老的活跃事务，即时间戳最小）和 oldest timestamp中的较小者，min（oldest_reader，oldest timestamp），并赋值 pinned timestamp。当进行历史版本数据的清理时，因为pinned timestamp = min（oldest_reader，oldest timestamp），所以 pinned timestamp 之后的版本不会被清理，从而保证了 mcp snapshot 的有效性。

2.2.4. mcp的更新

在了解mcp的更新之前，先了解一下insert的插入流程。Mongo的事务采用的是两阶段（2PC）提交：

Client 向Server层发送一条Insert命令，Server 层收到Insert命令之后会先获取一个锁，并调用LocalOplogInfo::getNextOpTimes() 来给其即将要写的 oplog entry 生成 ts 值。
Server 层会调用 WiredTigerRecoveryUnit::setTimestamp 开启 WiredTiger 引擎层的事务，后续这个事务中所有的写操作的 commit_ts 都设置为 oplog entry 的 ts
insert 操作在引擎层执行完成后，会把其对应的 oplog entry 也通过同一事务写到 WiredTiger Table 中，之后事务才提交
在第二步，就可以看到，commit_ts 和 oplog 的ts实际上是一样的。所以在mcp中的ts实际上就是oplog中的ts。
然后，再来看一下mcp是怎么更新的。mcp的更新分为主节点和从节点两个角度：

从从节点的角度来看：
- 心跳机制：
  - 默认情况下，每个副本集节点都会每 2 秒向其他成员发送心跳（ replSetHeartBeat 命令）
  - 其他成员返回的信息中会包含 $replData 元信息，Secondary 节点会根据其中的 lastOpCommitted 直接推进自己的 mcp
  - 心跳回复中，也包含了节点的lastAppliedOpTime 和 lastDurableOpTime。但是从节点一般都不会用这些来自己更新自己的mcp。总是等待主节点的lastOpCommittedOpTime传过来，然后直接设置。这样就可以尽可能的保证mcp跟主节点一致。
- 增量同步机制：心跳机制，每2秒发送一次消息，明显是不够实时的
  - 主从同步中，有一个oplog fetcher进程，是不断的从主节点拉取数据的。拉取的信息中就包含了 $replData 元信息。同样的会根据lastOpCommitted推荐mcp。
从主节点的角度来看：
- 心跳机制：可以根据从节点的心跳信息中的计算出mcp
- oplog增量同步：在主从同步章节中，我们可以知道，从节点是会不断的从主节点上拉取oplog进行同步的。从节点在apply完oplog之后，会向从节点返回进度。主节点就能通过这些信息来不断的更新自己的mcp。

2.2.5. local/available 实现

available跟local的语义相差并不是很大。主要区别在于，在分片场景下，available 可能会返回孤儿文档。
local 的语义理解起来很简单，但实现上却很复杂，涉及到重新选主，数据回滚和同步等等。这里不展开。后面单独写一篇文章用来说明。

2.2.6. majarity 实现

读取已经majority commited的数据。从前面的mcp的介绍，可以知道，mcp中的都是已经majority commited的数据，直接根据mcp判断即可。

2.2.7. linearizable 实现

linearizable保证线性一致性。既保证能读取到最新的数据（Recency Guarantee），也保证读到数据不会被回滚（Durability Guarantee）。Mongo为了简化linearizable的实现，将linearizable限定在主节点中执行。因为MongoDB的写操作，也只能在主节点中执行，因此将分布式的线性一致性，简化成单机的线性一致性。但还有两个分布式的问题是需要解决的：

重新选主：当读取过程中，主节点挂了，需要重新选主时。如何保证线性一致性
如何保证读操作是在最新的写操作之后，并且该写操作不会被回滚
Mongo用一个牺牲了延迟性的办法来解决这个办法。当Client指定了linearizable Read Concern时，在读取了主节点上最新的数据之后，会再新增一条noop的oplog，并且指定为majority write concern。如果这个noopoplog执行成功，则说明该oplog之前的数据，都已经满足了majority commited了。
这种实现方式很巧妙，但一个单纯的读操作，会触发写操作，而且，延迟也比较大。

2.2.8. snapshot 实现

snapshotread concern是专门用于多文档事务。如果一个事务涉及到多文档，无论是local还是majority，都会被升级到snapshot。值得注意的是，snapshot 还隐含了majority语义。
在事务开始通过begin transaction创建一个事务，并生成一个WiredTiger snapshot，然后在整个事务过程中读写都是使用这个事务ID，最后，通过commit transaction来结束事务。
为了保证性能，Mongo的事务也做了一些限制。