mvcc 订阅
Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。 展开全文
Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。
信息
避    免
使用锁
保    存
某个时间点上的数据快照
增    加
并发性
中文名
MVCC
被称为
多版本并发控制
MVCC产品简介
大多数的MySQL事务型存储引擎,如InnoDB,Falcon以及PBXT都在使用一种简单的行锁机制。事实上,他们都和另外一种用来增加并发性的被称为“多版本并发控制(MVCC)”的机制来一起使用。MVCC不只使用在MySQL中,Oracle、PostgreSQL,以及其他一些数据库系统也同样使用它。你可将MVCC看成行级别锁的一种妥协,它在许多情况下避免了使用锁,同时可以提供更小的开销。根据实现的不同,它可以允许非阻塞式读,在写操作进行时只锁定必要的记录。MVCC会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图,不管他们需要跑多久。这同时也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。如果你从来没有过这种体验的话,可能理解起来比较抽象,但是随着慢慢地熟悉这种理解将会很容易。各个存储引擎对于MVCC的实现各不相同。这些不同中的一些包括乐观和悲观并发控制。我们将通过一个简化的InnoDB版本的行为来展示MVCC工作的一个侧面。InnoDB:通过为每一行记录添加两个额外的隐藏的值来实现MVCC,这两个值一个记录这行数据何时被创建,另外一个记录这行数据何时过期(或者被删除)。但是InnoDB并不存储这些事件发生时的实际时间,相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ时这种策略是如何应用到特定的操作的:SELECT InnoDB必须每行数据来保证它符合两个条件:1、InnoDB必须找到一个行的版本,它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前,或者事务创建时,或者修改了这行数据的时候,这行数据是存在的。2、这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。这里的不是真正的删除数据,而是标志出来的删除。真正意义的删除是在commit的时候。符合这两个条件的行可能会被当作查询结果而返回。INSERT:InnoDB为这个新行记录当前的系统版本号。DELETE:InnoDB将当前的系统版本号设置为这一行的删除ID。UPDATE:InnoDB会写一个这行数据的新拷贝,这个拷贝的版本为当前的系统版本号。它同时也会将这个版本号写到旧行的删除版本里。这种额外的记录所带来的结果就是对于大多数查询来说根本就不需要获得一个锁。他们只是简单地以最快的速度来读取数据,确保只选择符合条件的行。这个方案的缺点在于存储引擎必须为每一行存储更多的数据,做更多的检查工作,处理更多的善后操作。MVCC只工作在REPEATABLE READ和READ COMMITED隔离级别下。READ UNCOMMITED不是MVCC兼容的,因为查询不能找到适合他们事务版本的行版本;它们每次都只能读到最新的版本。SERIABLABLE也不与MVCC兼容,因为读操作会锁定他们返回的每一行数据 [1]  。
收起全文
精华内容
下载资源
问答
  • MVCC

    2021-03-11 18:35:19
    MVCC多版本并发控制 爱情小傻蛋 5 2019.09.28 23:23:37 字数 4,740 阅读 46,213 前提概要 什么是MVCC 什么是当前读和快照读? 当前读,快照读和MVCC的关系 MVCC实现原理 隐式字段 undo日志 Read View(读视图) 整体...

    一、MVCC实现机制

    链接: link.

    2、MVCC的实现原理

    MVCC的目的就是多版本并发控制,在数据库中的实现,就是为了解决读写冲突,它的实现原理主要是依赖记录中的 3个隐式字段,undo日志 ,Read View 来实现的。
    每行记录除了我们自定义的字段外,还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段
    DB_TRX_ID
    6byte,最近修改(修改/插入)事务ID:记录创建这条记录/最后一次修改该记录的事务ID
    DB_ROLL_PTR
    7byte,回滚指针,指向这条记录的上一个版本(存储于rollback segment里)
    DB_ROW_ID
    6byte,隐含的自增ID(隐藏主键),如果数据表没有主键,InnoDB会自动以DB_ROW_ID产生一个聚簇索引
    实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除,而是删除flag变了

    在这里插入图片描述
    核心原理:我们知道 Read View主要是用来做可见性判断的, 即当我们某个事务执行快照读的时候,对该记录创建一个Read View读视图,把它比作条件用来判断当前事务能够看到哪个版本的数据,既可能是当前最新的数据,也有可能是该行记录的undo log里面的某个版本的数据。

    Read View遵循一个可见性算法,主要是将要被修改的数据的最新记录中的DB_TRX_ID(即当前事务ID)取出来,与系统当前其他活跃事务的ID去对比(由Read View维护),如果DB_TRX_ID跟Read View的属性做了某些比较,不符合可见性,那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较,即遍历链表的DB_TRX_ID(从链首到链尾,即从最近的一次修改查起),直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本

    作者:爱情小傻蛋
    链接:https://www.jianshu.com/p/8845ddca3b23
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    read view重的核心数据

    trx_list(名字我随便取的)
    一个数值列表,用来维护Read View生成时刻系统正活跃的事务ID
    up_limit_id
    记录trx_list列表中事务ID最小的ID
    low_limit_id
    ReadView生成时刻系统尚未分配的下一个事务ID,也就是目前已出现过的事务ID的最大值+1
    当一个事务获取一条数据的时候首先获取到read view(不同的隔离级别获取的时机不同)然后获取到当前数据的DB_TRX_ID(当前数据的事务id,也就是最后一次插入或者修改该记录的事务id)

    1.首先比较DB_TRX_ID < up_limit_id, 如果小于,则当前事务能看到DB_TRX_ID 所在的记录,如果大于等于进入下一个

    2.判断接下来判断 DB_TRX_ID 大于等于 low_limit_id , 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的,那对当前事务肯定不可见,如果小于则进入下一个判断

    1. up_limit_id <DB_TRX_ID<low_limit_id 判断DB_TRX_ID 是否在活跃事务之中,trx_list.contains(DB_TRX_ID),如果在,则代表我Read View生成时刻,你这个事务还在活跃,还没有Commit,你修改的数据,我当前事务也是看不见的
    2. up_limit_id <DB_TRX_ID<low_limit_id 判断DB_TRX_ID 是否在活跃事务之中,trx_list.contains(DB_TRX_ID),如果在 如果不在,则说明,你这个事务在Read View生成之前就已经Commit了,你修改的结果,我当前事务是能看见的

    对于不同隔离级别下以上三种所表现出的效果

    可重复读 读已提交
    第一种情况 因为当前数据的事务id 一定不会是在当前事务生成的read view 之后生成的(up_limit_id <low_limit_id ),所以这条数据一定是 在当前事务生成read view 之前最新更改或者新增的数据的事务id(原理同一) 因为每次获取的都是最新的read view 所以当前的数据一定是最新
    第二种情况 当前的事务id大于 read view中的最大事务 当前记录是在第一次读取之后生成的不可见 因为每次读取的都是最新的read view 而low_limit_id又等于当前生成时刻系统尚未分配的下一个事务ID 所以这种情况不会存在
    第三种情况 因为当前事务在生成read view时 DB_TRX_ID事务还在活跃中 并未提交所以当前事务看不到 这个时候会通过DB_ROLL_PTR 回滚指针 找到redo log中的上一条记录 重复执行read view的判断 因为每次读取的都是最新的read view 所以不可能存在一个事务id既在当前数据的事务id 又在活跃事务id里面 所以这种情况不会存在
    第三种情况 因为当前事务在生成read view时 DB_TRX_ID事务还在活跃中 并未提交所以当前事务看不到 这个时候会通过DB_ROLL_PTR 回滚指针 找到redo log中的上一条记录 重复执行read view的判断 因为每次读取的都是最新的read view 所以不可能存在一个事务id既在当前数据的事务id 又在活跃事务id里面 所以这种情况不会存在
    第四种情况 因为当前数据的事务id 一定不会是在当前事务生成的read view 之后生成的(up_limit_id <low_limit_id ),所以这条数据一定是 在当前事务生成read view 之前最新更改或者新增的数据的事务id(原理同一) 每次获取最新并且还不在活跃事务id 里面 所以该数据一定是 当前事务生成read view最新来记录

    RC每次读取生成新的read view ,RR(同一个事务只会生成一次 后面读取都用前面的)

    展开全文
  • mvcc

    2020-09-06 16:22:18
    什么是MVCC 1.1 基础概念 MVCC,Multi-Version Concurrency Control,多版本并发控制。MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。 如果有人从数据库...

    什么是MVCC
    1.1 基础概念
    MVCC,Multi-Version Concurrency Control,多版本并发控制。MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。
    如果有人从数据库中读数据的同时,有另外的人写入数据,有可能读数据的人会看到『半写』或者不一致的数据。有很多种方法来解决这个问题,叫做并发控制方法。最简单的方法,通过加锁,让所有的读者等待写者工作完成,但是这样效率会很差。MVCC 使用了一种不同的手段,每个连接到数据库的读者,在某个瞬间看到的是数据库的一个快照,写者写操作造成的变化在写操作完成之前(或者数据库事务提交之前)对于其他的读者来说是不可见的。
    当一个 MVCC 数据库需要更一个一条数据记录的时候,它不会直接用新数据覆盖旧数据,而是将旧数据标记为过时(obsolete)并在别处增加新版本的数据。这样就会有存储多个版本的数据,但是只有一个是最新的。这种方式允许读者读取在他读之前已经存在的数据,即使这些在读的过程中半路被别人修改、删除了,也对先前正在读的用户没有影响。这种多版本的方式避免了填充删除操作在内存和磁盘存储结构造成的空洞的开销,但是需要系统周期性整理(sweep through)以真实删除老的、过时的数据。对于面向文档的数据库(Document-oriented database,也即半结构化数据库)来说,这种方式允许系统将整个文档写到磁盘的一块连续区域上,当需要更新的时候,直接重写一个版本,而不是对文档的某些比特位、分片切除,或者维护一个链式的、非连续的数据库结构。
    MVCC 提供了时点(point in time)一致性视图。MVCC 并发控制下的读事务一般使用时间戳或者事务 ID去标记当前读的数据库的状态(版本),读取这个版本的数据。读、写事务相互隔离,不需要加锁。读写并存的时候,写操作会根据目前数据库的状态,创建一个新版本,并发的读则依旧访问旧版本的数据。
    一句话讲,MVCC就是用 同一份数据临时保留多版本的方式 的方式,实现并发控制。
    这里留意到 MVCC 关键的两个点:
    在读写并发的过程中如何实现多版本;
    在读写并发之后,如何实现旧版本的删除(毕竟很多时候只需要一份最新版的数据就够了);

    展开全文

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,958
精华内容 2,383
热门标签
关键字:

mvcc