MongoDB事务的理解和思考

  1. 3.2版本开始引入Read Concern,解决了脏读,支持Read Commit

  2. 3.6版本引入Session,支持多个请求共享上下文,为后续的事务支持做准备

  3. 4.0支持多行事务,但4.0的事务只是个过渡的版本

  4. 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 最新的时间戳

  1. 开启 WiredTiger 引擎层的一个事务,这个事务在提交时会顺便记录本次写操作对应的 Oplog
    Entry 的时间戳

  2. 执行 ReplicationCoordinatorImpl::_awaitReplication_inlock 阻塞在一个条件变量,等待N个从节点完成

  3. 被阻塞的用户线程会被加入到 _replicationWaiterList 中,从节点完成后,唤醒该线程

  4. 从节点会不断从主节点上拉取oplog,在执行完后会更新自己的点位信息,同时还会有另一个后台进程,向主节点不断的汇报当前从节点的appliedOpTime 和 durableOpTime。

  5. 主节点的唤醒逻辑中,维护着一个lastOptime,如果 j 为false,则取从节点的appliedOpTime,否则就取durableOpTime

  6. 如果从节点的opTime,大于或者等于主节点的opTime,则认为从节点已经Apply完成

  7. 等待有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引擎相比较,PostgreSQLMongoDB的MVCC实现方式的优缺点如下。

优点:

  1. 事务回滚可以立即完成,无论事务进行了多少操作;

  2. 数据可以进行高频更新,不必像Oracle和MySQL的Innodb引擎那样需要经常保证回滚段不会被用完,也不会像oracle数据库那样经常遇到“ORA-1555”错误的困扰;

缺点:

  1. 旧版本数据需要清理。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)提交:

  1. Client 向Server层发送一条Insert命令,Server 层收到Insert命令之后会先获取一个锁,并调用LocalOplogInfo::getNextOpTimes() 来给其即将要写的 oplog entry 生成 ts 值。

  2. Server 层会调用 WiredTigerRecoveryUnit::setTimestamp 开启 WiredTiger 引擎层的事务, 后续这个事务中所有的写操作的 commit_ts 都设置为 oplog entry 的 ts

  3. insert 操作在引擎层执行完成后,会把其对应的 oplog entry 也通过同一事务写到 WiredTiger Table 中,之后事务才提交
    在第二步,就可以看到,commit_ts 和 oplog 的ts实际上是一样的。 所以在mcp中的ts实际上就是oplog中的ts。
    然后,再来看一下mcp是怎么更新的。mcp的更新分为主节点和从节点两个角度:

  • 从节点的角度来看:

    • 心跳机制:

      • 默认情况下,每个副本集节点都会每 2 秒向其他成员发送心跳( replSetHeartBeat 命令)

      • 其他成员返回的信息中会包含 $replData 元信息,Secondary 节点会根据其中的 lastOpCommitted 直接推进自己的 mcp

      • 心跳回复中,也包含了节点的lastAppliedOpTimelastDurableOpTime。但是从节点一般都不会用这些来自己更新自己的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的写操作,也只能在主节点中执行,因此将分布式的线性一致性,简化成单机的线性一致性。但还有两个分布式的问题是需要解决的:

  1. 重新选主:当读取过程中,主节点挂了,需要重新选主时。如何保证线性一致性

  2. 如何保证读操作是在最新的写操作之后,并且该写操作不会被回滚
    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的事务也做了一些限制。

  1. 事务的生命周期不能超过 transactionLifetimeLimitSeconds (默认60s),该配置可在线修改

  2. 事务修改的文档数不能超过 1000 ,不可修改

  3. 事务修改产生的 oplog 不能超过 16mb,这个主要是 MongoDB 文档大小的限制, oplog 也是一个普通的文档,也必须遵守这个约束。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mfbz.cn/a/622870.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

具备教学意义的实操(用栈实现队列)

具备教学意义的实操(用队列实现栈)-CSDN博客https://blog.csdn.net/Jason_from_China/article/details/138729955 具备教学意义的实操(用栈实现队列) 题目 232. 用栈实现队列 - 力扣(LeetCode) ​ 逻辑​​…

一、VIsual Studio下的Qt环境配置(Visual Studio 2022 + Qt 5.12.10)

一、下载编译器Visual Studio2022和Qt 5.12.10 Visual Studio 2022 社区版就够学习使用了 Qt5.12.10 安装教程网上搜,一大堆 也很简单,配置直接选默认,路径留意一下即可 二、配置环境 Ⅰ,配置Qt环境变量 系统变量下的Path&a…

C++的数据结构(五):树和存储结构及示例

在计算机科学中,树是一种抽象数据类型(ADT)或是实现这种抽象数据类型的数据结构,用来模拟具有树状结构性质的数据集合。这种数据结构以一系列连接的节点来形成树形结构。在C中,树的概念和存储结构是实现各种复杂算法和…

Golang | Leetcode Golang题解之第87题扰乱字符串

题目: 题解: func isScramble(s1, s2 string) bool {n : len(s1)dp : make([][][]int8, n)for i : range dp {dp[i] make([][]int8, n)for j : range dp[i] {dp[i][j] make([]int8, n1)for k : range dp[i][j] {dp[i][j][k] -1}}}// 第一个字符串从 …

61、内蒙古工业大学、内蒙科学技术研究院:CBAM-CNN用于SSVEP - BCI的分类方法[脑机二区还是好发的]

前言: 之前写过一篇对CBAM模型改进的博客,在CBAM中引入了ECANet结构,对CBAM中的CAM、SAM模块逐一改进,并提出ECA-CBAM单链双链结构,我的这个小的想法已经被一些同学实现了,并进行了有效的验证,…

算法-卡尔曼滤波之为什么要使用卡尔曼滤波器

假设使用雷达来预测飞行器的位置; 预先的假设条件条件: 1.激光雷达的激光束每5s发射一次; 2.通过接受的激光束,雷达估计目标当前时刻的位置和速度; 3.同时雷达要预测下一时刻的位置和速度 根据速度,加速度和位移的…

ROS2 - 创建项目 (Ubuntu22.04)

本文简述:在 Ubuntu22.04 系统中使用 VS CODE 来搭建一个ROS2开发项目。 1. 创建工作空间 本文使用 Ubuntu 22.04, 已安装配置完成 VS Code,C 环境(g/gdb) 1.1 创建目录 选择文件夹作为工作空间,并在这…

Django开发实战之定制管理后台界面及知识梳理(下)

接上一篇:Django开发实战之定制管理后台界面及知识梳理(中) 1、前台设置 1、隐藏路由 当你输入一个错误地址时,可以看到这样的报错: 从这样的报错中,我们可以看到,这个报错页面暴漏了路由&a…

数据结构-题目

1.已知一颗完全二叉树的第6曾(设根为第1层),有8个结点,则完全二叉树的结点个数,最少和最多分别是多少? 因此最少为39,最多为111 2.假设一棵三叉树的结点数为50,则它的最小高度为&…

【数据结构与算法 刷题系列】合并两个有序链表

💓 博客主页:倔强的石头的CSDN主页 📝Gitee主页:倔强的石头的gitee主页 ⏩ 文章专栏:数据结构与算法刷题系列(C语言) 目录 一、问题描述 二、解题思路详解 合并两个有序链表的思路 解题的步…

[PythonWeb:Django框架]:前后端请求调用;

文章目录 接着上篇项目app包下面创建static包,引入jquery,bootstrap 相关js文件views.py编写apicompute文件夹下面的urls.py路由模块引入views.py刚刚定义的函数html发送ajax请求 接着上篇 https://blog.csdn.net/Abraxs/article/details/138739727?sp…

【pouchdb-可视化工具 】

最近使用pouchdb,想找个其对应的可视化工具,可以对数据库进行操作。 找了好久才找到,网上有说先同步到couchdb,再用couchdb的可视化工具查看,其实没有那么麻烦,pouchdb的可视化工具其实藏在另外的pouchdb-…

让创意在幻觉中肆虐: 认识Illusion Diffusion AI

人工智能新境界 在不断发展的人工智能领域,一款非凡的新工具应运而生,它能将普通照片转化为绚丽的艺术品。敬请关注Illusion Diffusion,这是一个将现实与想象力完美融合的AI驱动平台,可创造出迷人的视错觉和超现实意境。 AI算法的魔力所在 Illusion Diffusion 的核心是借助先进…

react Effect副作用 - 避免滥用Effect

react Effect副作用 - 避免滥用Effect react Effect副作用基础概率什么是纯函数? 什么是副作用函数?纯函数副作用函数 什么时候使用Effect如何使用Effect 避免滥用Effect根据 props 或 state 来更新 state当 props 变化时重置所有 state将数据传递给父组件获取异步数据 react…

持续集成-Git

重要步骤命令 git init (初始化一个仓库) git add [文件名] (添加新的文件) git commit -m [关于本次提交的相关说明] (提交) git status (查看文件状态) git diff (如果文件改变,比较两个文件内容) git add[文件名] || git commit -a -m [关于本次提交的相关说…

RiProV2主题美化【支付页弹窗增加价格提示语】Ritheme主题美化RiProV2-网站WordPress美化二开

背景: 楼主的网站是用WordPress搭建的,并使用了正版主题RiProV2,但RiProV2在支付弹窗页没有价格,只在文章详情页会展示价格。本文就是美化这个支付弹窗,在支付弹窗页把价格字段加上,如下图所示: 美化前: 美化后 美化步骤: (1)定位到文件:/www/wwwroot/www.uu2i…

免费思维13招之九:时间型思维

免费思维13招之九:时间型思维 免费思维的另一大战略思维——时间型思维。 什么是时间型思维呢?就是在某一个规定的时间内对消费者进行免费,比如一个月中的某一天,或一周中的某一天或一天中的某一个时间段对消费者进行免费。 就在去年,有一个电影院老板弟子,他的电影院营…

增强型植被指数EVI、ndvi数据、NPP数据、GPP数据、土地利用数据、植被类型数据、降雨量数据

引言 多种卫星遥感数据反演增强型植被指数(EVI)产品是地理遥感生态网推出的生态环境类数据产品之一,产品包括1986-2021年度月度数据,数据类型tif栅格数据。该产品经过专家组验证,质量良好。 正文 栅格数据源 数据名…

【JavaEE】Web服务器与请求响应流程:深入了解如何处理Web请求

目录 Web服务器请求响应流程分析小结 Web服务器 浏览器和服务器两端进⾏数据交互, 使⽤的就是HTTP协议 前⾯我们已经学习了 HTTP 协议, 知道了 HTTP 协议就是 HTTP 客⼾端和 HTTP 服务器之间的交互数据的格式. Web 服务器就是对HTTP协议进⾏封装, 程序员不需要直接对协议进⾏…

开关电源功率测试方法:输入、输出功率测试步骤

在现代电子设备中,开关电源扮演着至关重要的角色,其效率和稳定性直接影响到整个系统的性能。因此,对开关电源进行功率测试成为了电源管理的重要环节。本文将详细介绍如何使用DC-DC电源模块测试系统对开关电源的输入输出功率进行准确测量&…