MongoDB 4.0 系列之\b —— 事务实现解析(\b\b二)

MongoDB 4.0 引入的事务功能,支持多文档ACID特性,例如使用 mongo shell 进行事务操作。

支持 MongoDB 4.0 的其他语言 Driver 也封装了事务相关接口,用户需要创建一个 Session,然后在 Session 上开启事务,提交事务。例如:

>>>>

python 版本

>>>> java 版本

Part.1

Session

Session 是 MongoDB 3.6 版本引入的概念,引入这个特性主要就是为实现多文档事务做准备。Session 本质上就是一个「上下文」。

在以前的版本,MongoDB 只管理单个操作的上下文,MongoDB服务进程接收到一个请求,为该请求创建一个上下文 (源码里对应 OperationContext),然后在服务整个请求的过程中一直使用这个上下文,内容包括,请求耗时统计、请求占用的锁资源、请求使用的存储快照等信息。有了 Session 之后,就可以让多个请求共享一个上下文,让多个请求产生关联,从而有能力支持多文档事务。

每个 Session 包含一个唯一的标识 lsid,在 4.0 版本里,用户的每个请求可以指定额外的扩展字段,主要包括:

  • lsid: 请求所在 Session 的 ID, 也称 logic session id
  • txnNmuber:请求对应的事务号,事务号在一个 Session 内必须单调递增
  • stmtIds:对应请求里每个操作(以insert为例,一个insert命令可以插入多个文档)操作ID

实际上,用户在使用事务时,是不需要理解这些细节,MongoDB Driver 会自动处理,Driver 在创建 Session 时分配 lsid,接下来这个 Session 里的所有操作,Driver 会自动为这些操作加上 lsid,如果是事务操作,会自动带上 txnNumber。

值得一提的是,Session lsid 可以通过调用 startSession 命令让 server 端分配,也可以客户端自己分配,这样可以节省一次网络开销;而事务的标识,MongoDB 并没有提供一个单独的 startTransaction的命令,txnNumber 都是直接由 Driver 来分配的,Driver 只需保证一个 Session 内,txnNumber 是递增的,server 端收到新的事务请求时,会主动的开始一个新事务。

MongoDB 在 startSession 时,可以指定一系列的选项,用于控制 Session 的访问行为,主要包括:

Part.2

ACID

Atomic

针对多文档的事务操作,MongoDB 提供 “All or nothing” 的原子语义保证。

Consistency

太难解释了,还有抛弃 Consistency 特性的数据库?

Isolation

MongoDB 提供 snapshot 隔离级别,在事务开始创建一个 WiredTiger snapshot,然后在整个事务过程中使用这个快照提供事务读。

Durability

事务使用 WriteConcern {j: ture} 时,MongoDB 一定会保证事务日志提交才返回,即使发生 crash,MongoDB 也能根据事务日志来恢复;而如果没有指定 {j: true} 级别,即使事务提交成功了,在 crash recovery 之后,事务的也可能被回滚掉。

Part.3

事务与复制

复制集配置下,MongoDB 整个事务在提交时,会记录一条 oplog(oplog 是一个普通的文档,所以目前版本里事务的修改加起来不能超过文档大小 16MB的限制),包含事务里所有的操作,备节点拉取oplog,并在本地重放事务操作。

事务 oplog 示例,包含事务操作的 lsid,txnNumber,以及事务内所有的操作日志(applyOps字段)

整个重放过程如下:

  1. 获取当前 Batch (后台不断拉取 oplog 放入 Batch)
  2. 设置 OplogTruncateAfterPoint 时间戳为 Batch里第一条 oplog 时间戳 (存储在 local.replset.oplogTruncateAfterPoint 集合)
  3. 写入 Batch 里所有的 oplog 到 local.oplog.rs 集合,根据 oplog 条数,如果数量较多,会并发写入加速
  4. 清理 OplogTruncateAfterPoint, 标识 oplog 完全成功写入;如果在本步骤完成前 crash,重启恢复时,发现 oplogTruncateAfterPoint 被设置,会将 oplog 截短到该时间戳,以恢复到一致的状态点。
  5. 将 oplog 划分到到多个线程并发重放,为\u0010\u0010\u0010\u0010\u0010\u0010了提升并发效率,事务产生的 oplog 包含的所有修改操作,跟一条普通单条操作的 oplog 一样,会据\u0010\u0010\u0010\u0010文档ID划分到多个线程。
  6. 更新 ApplyThrough 时间戳为 Batch 里最后一条 oplog 时间戳,标识下一次重启后,从该位置重新同步,如果本步骤之前失败,重启恢复时,会从 ApplyThrough 上一次的值(上一个 Batch 最后一条 oplog)拉取 oplog。
  7. 更新 oplog 可见时间戳,如果有其他节点从该备节点同步,此时就能读到这部分新写入的 oplog
  8. 更新本地 Snapshot(时间戳),新的写入将对用户可见。

Part.4

事务与存储引擎

事务时序统一

WiredTiger 很早就支持事务,在 3.x 版本里,MongoDB 就通过 WiredTiger 事务,来保证一条修改操作,对数据、索引、oplog 三者修改的原子性。但实际上 MongoDB 经过多个版本的迭代,才提供了事务接口,核心难点就是时序问题。

通过 oplog 时间戳来标识全局顺序,而 WiredTiger 通过内部的事务ID来标识全局顺序,在实现上,2者没有任何关联。这就导致在并发情况下, MongoDB 看到的事务提交顺序与 WiredTiger 看到的事务提交顺序不一致。

为解决这个问题,WiredTier 3.0 引入事务时间戳(transaction timestamp)机制,应用程序可以通过 WT_SESSION::timestamp_transaction 接口显式的给 WiredTiger 事务分配 commit timestmap,然后就可以实现指定时间戳读(read "as of" a timestamp)。有了 read "as of" a timestamp 特性后,在重放 oplog 时,备节点上的读就不会再跟重放 oplog 有冲突了,不会因重放 oplog 而阻塞读请求,这是4.0版本一个巨大的提升。

从上面的代码可以看到,再引入事务时间戳之后,在可见性判断时,还会额外检查时间戳,上层读取时指定了时间戳读,则只能看到该时间戳以前的数据。而 MongoDB 在提交事务时,会将 oplog 时间戳跟事务关联,从而达到 MongoDB Server 层时序与 WiredTiger 层时序一致的目的。

事务对 cache 的影响

WiredTiger(WT) 事务会打开一个快照,而快照的存在的 WiredTiger cache evict 是有影响的。一个 WT page 上,有N个版本的修改,如果这些修改没有全局可见(参考 __wt_txn_visible_all),这个 page 是不能 evict 的(参考 __wt_page_can_evict)。

在 3.x 版本里,一个写请求对数据、索引、oplog的修改会放到一个 WT 事务里,事务的提交由 MongoDB 自己控制,MongoDB 会尽可能快的提交事务,完成写清求;但 4.0 引入事务之后,事务的提交由应用程序控制,可能出现一个事务修改很多,并且很长时间不提交,这会给 WT cache evict 造成很大的影响,如果大量内存无法 evict,最终就会进入 cache stuck 状态。

为了尽量减小 WT cache 压力,MongoDB 4.0 事务功能有一些限制,但事务资源占用超过一定阈值时,会自动 abort 来释放资源。规则包括

  1. 事务的生命周期不能超过 transactionLifetimeLimitSeconds (默认60s),该配置可在线修改
  2. 事务修改的文档数不能超过 1000 ,不可修改
  3. 事务修改产生的 oplog 不能超过 16mb,这个主要是 MongoDB 文档大小的限制, oplog 也是一个普通的文档,也必须遵守这个约束。

Read as of a timestamp 与 oldest timestamp

Read as of a timestamp依赖 WiredTiger 在内存里维护多版本,每个版本跟一个时间戳关联,只要 MongoDB 层可能需要读的版本,引擎层就必须维护这个版本的资源,如果保留的版本太多,也会对 WT cache 产生很大的压力。

WiredTiger 提供设置 oldest timestamp 的功能,允许由 MongoDB 来设置该时间戳,含义是Read as of a timestamp 不会提供更小的时间戳来进行一致性读,也就是说,WiredTiger 无需维护 oldest timestamp 之前的所有历史版本。MongoDB 层需要频繁(及时)更新 oldest timestamp,避免让 WT cache 压力太大。

引擎层 Rollback 与 stable timestamp

在 3.x 版本里,MongoDB 复制集的回滚动作是在 Server 层面完成,但节点需要回滚时,会根据要回滚的 oplog 不断应用相反的操作,或从回滚源上读取最新的版本,整个回滚操作效率很低。

4.0 版本实现了存储引擎层的回滚机制,当复制集节点需要回滚时,直接调用 WiredTiger 接口,将数据回滚到某个稳定版本(实际上就是 Checkpoint),这个稳定版本则依赖于 stable timestamp。WiredTiger 会确保 stable timestamp 之后的数据不会写到 Checkpoint里,MongoDB 根据复制集的同步状态,当数据已经同步到大多数节点时(Majority commited),会更新 stable timestamp,因为这些数据已经提交到大多数节点了,一定不会发生 ROLLBACK,这个时间戳之前的数据就都可以写到 Checkpoint 里了。

MongoDB 需要确保频繁(及时)的更新 stable timestamp,否则影响 WT Checkpoint 行为,导致很多内存无法释放。例如主备延时很大,导致数据一直没有被同步到大多数节点,这时主上 stable timestamp 就无法更新,内存不断积累就可能把 cache 撑满。

Part.5

分布\u0010\u0010式事务

MongoDB 4.0 支持副本集多文档事务,并计划在 4.2 版本支持分片集群事务功能。下图是从 MongoDB 3.0 引入 WiredTiger 到 4.0 支持多文档事务的功能迭代图,可以发现一盘大棋即将上线,敬请期待。

作者:张友东

本文分享自微信公众号 - Mongoing中文社区(mongoing-mongoing)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-07-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏DannyHoo的专栏

学习git的一些命令

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010105969/article/details/...

10530
来自专栏无所事事者爱嘲笑

mac上配置react-native环境run-ios/run-android命令遇到的问题

22930
来自专栏java思维导图

单点登录(SSO),从原理到实现

如果你觉得文字太长,可以直接先看文末思维导图总结,小编已为你整理了作者的主要观点,供你回顾与快速阅读~

4K80
来自专栏码神联盟

Nginx | Java工程师必备课 之 Linux下安装Nginx

29730
来自专栏雨过天晴

原 PHPStrom 9系列激活码

25040
来自专栏黑泽君的专栏

【MyEclipse】我们导入的jar包后, 一般没有关联源码, 需要手动进行关联!推荐这种方式。

12350
来自专栏云计算教程系列

如何在Debian 8上用mod_proxy将Apache设置为反向代理

reverse proxy(反向代理)是一种代理服务器,它接收HTTP(S)请求并将它们透明地分发到一个或多个后端服务器。反向代理非常实用,因为许多现代Web应...

13330
来自专栏开源优测

AutoLink开源平台主入口代码分析

github地址:https://github.com/small99/AutoLink

18820
来自专栏任浩强的运维生涯

调用redis的时候二维码不断刷新的排查

一、背景和现象。 项目是PHP开发的,点击登录的时候就根据随机数生成了二维码,缓存在了redis。用户用微信扫描了二维码分析出需要请求的链接,然后微信浏览器就请...

37950
来自专栏程序员互动联盟

程序员最爱说的8句谎言

1.我以后再给代码写注释和文档 2.就改一行代码,不会影响其他东西的 3.这 Bug 不在我代码中,你肯定使用姿势不对啊! 4.下次修改代码时我会增加单元测试 ...

38850

扫码关注云+社区

领取腾讯云代金券