mysql的两阶段协议(封锁定理,虫洞事务)

  我们都知道数据库的事务具有ACID的四个属性:原子性,一致性,隔离性和持久性。然后在多线程操作的情况下,如果不能保证事务的隔离性,就会造成数据的修改丢失(事务2覆盖了事务1的修改结果)、读到脏数据(事务2读到了事务1未回滚的数据)、不可重读(事务2读到了事务1未提交的修改)和幻读(事务2读到了事务1未提交的增删)等。保证事务隔离性可以防止事务出现以上问题,那么数据库又是怎么来保证事务的隔离性的呢?

  mysql使用两阶段协议来保证事务执行的串行化从而保证事务的隔离性的。
  首先,为了保证数据访问的串行,每个数据资源都有对应的锁(mysql的锁只细化到行级),那么只要保证每个数据资源的访问都是串行化的,然后整个数据库不就可以保证每个数据操作之间的隔离性了么,就是说:

  只要每个数据操作都有对应的锁覆盖,然后把每个操作都加上对应的锁,这样可以保证事务执行的串行化么?

  答案是:可以保证,但是有个前提是每个事务只包含对一个数据的操作。事实上mysql也默认是这样做的:如果用户没有手动开启事务,那么根据AUTOCOMMIT机制,mysql默认将每一个数据库操作封装成一个事务来处理。

  然而实际情况中,很多时候一个事务不只包含一个数据库操作,比如电商平台在生成订单时,一个事务里包含了对订单表、用户表、商品表等的操作。在多线程操作的情况下,如果只用数据库的锁来保证的话,就会出现上面所提到的一些数据异常情况。这时候就需要两阶段协议来保证事务的隔离性了。那么进入今天的主题:

  两阶段协议如何保证多事务操作之间的隔离性?

  上面说过,只要事务执行是串行的,事务之间就是隔离的,在网上搜索两阶段协议为何能保证串行化,只搜到一个封锁定理:如果事务是良构的且是两阶段的,那么任何一个合法的调度都是可串行化的。 既然是定理,那一定是严格成立且可证明的,于是顺藤摸瓜,找到了封锁定理的证明(<事务处理:概念与技术>>这本书的7.5.8.2节)。

  首先我们解析命题:

  条件:良构的事务、两阶段、合法的调度

  结论:是可串行化的。

  在书上找到条件的描述:

  如果事务的每个READ、WRITE、 UNLOCK都被响应的锁覆盖,且所有的锁都是在事务结束时释放,那么称这样的事物是良构的。(mysql的表和行数据在被操作时,都有对应的锁覆盖) 

  如果一个事务可以分成两个阶段,只请求封锁的扩展阶段和只释放锁的收缩阶段,那么称之为两阶段的事务。(mysql采用两阶段封锁协议)

  调度是一组事务的操作的某种合并结果。(mysql支持多事务并行执行)

  一个调度是合法的,如果同一时间没发生两个不同事务的锁冲突。(mysql需要保证并行事务不冲突)

  因为每个事务T都是良构的,所以必定对应着一个解锁操作Unlock,事务T的解锁操作步骤在调度中的索引为St。

  假设在调度中事务T1在事务T2之前执行,T1<<<T2,则事务T2依赖事务T1,使得事务T1对对象O的操作步骤a1在事务T2对对象O的操作步骤a2之前,那么a1和a2必定有一个步骤对象O正覆盖着排他锁(WRITE)(因为如果是两个挨着的读事务(READ)不存在依赖关系,所以他们的执行顺序没有明确的等价执行序列),如果是a1时对象O覆盖着一个XLOCK(排他锁),a2时对象O应该覆盖着一个SLOCK(共享锁)或XLOCK(排他锁),与前面的XLOCK互斥,又由于是两阶段的,所以在a1和a2之间,会存在一个事务T1给对象O解锁的Unlock操作步骤St1,事务T2的解锁操作步骤St2在a2之后,所以有:St1<<<St2,即事务T1的解锁在事务T2的解锁之前。同理在a2是WRITE操作的时候也成立。如果调度是不可串行化的,那么必然存在T1<<<T2时,St2<<<St1,与上述结论矛盾,所以:

  如果一个调度包含的事物都是良构的且为两阶段的,那么该调度是可串行化的。

  可能有人会问,为什么不给每个事务加排他锁来保证多事务执行的串行化呢?

  是因为如果把读锁也定义为排他锁的话,会大大的降低并发读的效率,而查询操作在数据库的操作中占了很大的比例,所以mysql默认采用的可重复读的隔离级别,用两阶段协议和全场景覆盖的锁来保证执行结果的串行化,并没有采用全用排他锁来保证串行化。

  

  

  

原文地址:https://www.cnblogs.com/yangshunxing/p/12019831.html

时间: 2024-10-07 03:46:55

mysql的两阶段协议(封锁定理,虫洞事务)的相关文章

MySQL binlog 组提交与 XA(两阶段提交)

1. XA-2PC (two phase commit, 两阶段提交 ) XA是由X/Open组织提出的分布式事务的规范(X代表transaction; A代表accordant?).XA规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口.XA为了实现分布式事务,将事务的提交分成了两个阶段:也就是2PC (tow phase commit),XA协议就是通过将事务的提交分为两个阶段来实现分布

MySQL binlog 组提交与 XA(分布式事务、两阶段提交)【转】

概念: XA(分布式事务)规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口.XA为了实现分布式事务,将事务的提交分成了两个阶段:也就是2PC (tow phase commit),XA协议就是通过将事务的提交分为两个阶段来实现分布式事务. 两阶段: 1)prepare 阶段 事务管理器向所有涉及到的数据库服务器发出prepare"准备提交"请求,数据库收到请求后执行数据修改和日志

聊一聊 MySQL 中的数据编辑过程中涉及的两阶段提交

MySQL 数据库中的两阶段提交,不知道您知道不?这篇文章就简单的聊一聊 MySQL 数据库中的两阶段提交,两阶段提交发生在数据变更期间(更新.删除.新增等),两阶段提交过程中涉及到了 MySQL 数据库中的两个日志系统:redo 日志和 binlog 文件. redo 日志前面已经介绍过了,就不再介绍了,简单的聊一聊 binlog 文件,binlog 是 MySQL server 层提供的二进制文件,因此所有的存储引擎都可以使用 binlog 功能,binlog 是追加写的逻辑日志,记录了执行

MySQL两阶段提交

参数介绍 innodb_flush_log_at_trx_commit 0: 每隔1s,系统后台线程刷log buffer,也就是把redo日志刷盘,这里会调用fsync,所以可能丢失最后1s的事务. 1: 每次commit时,刷redo日志,确定fsync刷盘 2: 每次提交时,刷redo日志到文件系统,不调用fsync刷盘,5.6.6之前是每隔1s刷盘,之后的版本是通过参数innodb_flush_log_at_timeout设置,默认也是1s.所以也可能丢最后一秒的事务.如果有掉电保护组件

mysql 2PC二阶段协义 与 日志闪回

mysql两份日志: binlog :server innodb redo log:engine 两份日志顺序一致性:否则主备不一致 两份日志:原子性,同时都有,同时都无 2PC二阶段协义: 第一阶段:准备界段 第二阶段:提交阶段 买房子示例 准备界段: 房产局确认: 买方:钱是否准备好 卖方:房子是否可卖 提交界段: 政务中心: 买方: 确认按手印 卖方:确认按手印 ----------------------------------------------------------------

关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究[转]

1.XA XA是由X/Open组织提出的分布式事务的规范.XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口.XA接口是双向的系统接口,在事务管理器(Transaction Manager)以及一个或多个资源管理器(Resource Manager)之间形成通信桥梁.XA之所以需要引入事务管理器是因为,在分布式系统中,从理论上讲(参考Fischer等的论文),两台机器理论上无法达到一致的状态,需要引入一

MySQL源码之两阶段提交

在双1的情况下,两阶段提交的过程 环境准备:mysql 5.5.18, innodb 1.1 version配置: sync_binlog=1 innodb_flush_log_at_trx_commit=1 autocommit=0 设置断点: sql_parse.cc::dispatch_command --命令跳转入口 sql_parse.cc::mysql_parse sql_parse.cc::mysql_execute_command sql_parse.cc::trans_comm

对分布式事务及两阶段提交、三阶段提交的理解

转载至:http://www.cnblogs.com/binyue/p/3678390.html,最近学习需要,先转载方便用用来强化加深印象 一.分布式数据一致性 在分布式系统中,为了保证数据的高可用,通常会将数据保留多个副本(replica),这些副本会放置在不同的物理的机器上. (1)什么是数据一致性 在数据有多份副本的情况下,如果网络.服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败.这就造成各个副本之间的数据不一致,数据内容冲突. 造成事实上的数据不一致. (2)CAP定

这篇文章关于两阶段提交和Paxos讲的很好

http://blog.chinaunix.net/uid-16723279-id-3803058.html <两阶段提交协议与paxos投票算法> 点评:2PC绝对是CP的死党,是分布式情况下强一致性算法,因此缺点也是很明显的, 单点coordinator是个严重问题: 没有热备机制,coordinator节点crash了或者连接它的网路坏了会阻塞该事务: 吞吐量不行,没有充分发动数量更多的participants的力量,一旦某个participant第一阶段投了赞成票就得在他上面加独占锁,