精华内容
下载资源
问答
  • 1)、原子性的实现 ‍原子性,是指一个事务必须被视为不可分割的最小单位,一个事务中的所有操作要么全部执行成功、要么全部失败回滚,对一个事务来说不可能只执行其中的部分操作,这就是事务原子性的概念。...

    “本文略长,但值得认真研读两遍!!!“

    在如今互联网业务中使用范围最广的数据库无疑还是关系型数据库MySQL,之所以用"还是"这个词,是因为最近几年国内数据库领域也取得了一些长足进步,例如以TIDB、OceanBase等为代表的分布式数据库,但它们暂时还没有形成绝对的覆盖面,所以现阶段还得继续学习MySQL数据库以应对工作中遇到的一些问题,以及面试过程中关于数据库部分的考察。

    今天的内容就和大家聊一聊MySQL数据库中关于并发控制、事务以及存储引擎这几个最核心的问题。本内容涉及的知识图谱如下图所示:

    并发控制


    并发控制是一个内容庞大的话题,在计算机软件系统中只要在同一时刻存在多个请求同时修改数据的情况,就都会产生并发控制的问题,例如Java中的多线程安全问题等。在MySQL中的并发控制,主要是讨论数据库如何控制表数据的并发读写。

    例如有一张表useraccount,其结构如下:

    此时如果有如下两条SQL语句同一时刻向数据库发起请求:

    SQL-A:

    update useraccount t set t.account=t.account+100 where username='wudimanong';

    SQL-B:

    update useraccount t set t.account=t.account-100 where username='wudimanong'

    当上述语句都执行完成,正确结果应该是account=100,但在并发情况下,却有可能发生这样的情况:

    那么在MySQL中是如何进行并发控制的呢?实际上与大多数并发控制方式一样,在MySQL中也是利用锁机制来实现并发控制的。

    01 MySQL锁类型

    在MySQL中主要是通过"读写锁"来实现并发控制。

    读锁(read lock):也叫共享锁(share lock),多个读请求可以同时共享一把锁来读取数据,而不会造成阻塞。

    写锁(write lock):也叫排他锁(exclusive lock),写锁会排斥其他所有获取锁的请求,一直阻塞,直到完成写入并释放锁。

    读写锁可以做到读读并行,但是无法做到写读、写写并行。后面会讲到的事务隔离性就是根据读写锁来实现的!

    02 MySQL锁粒度

    上面提及的读写锁是根据MySQL的锁类型来划分的,而读写锁能够施加的粒度在数据库中主要体现为表和行,也称为表锁(table lock)、行锁(row lock)

    表锁(table lock):是MySQL中最基本的锁策略,它会锁定整张表,这样维护锁的开销最小,但是会降低表的读写效率。如果一个用户通过表锁来实现对表的写操作(插入、删除、更新),那么先需要获得锁定该表的写锁,那么在这种情况下,其他用户对该表的读写都会被阻塞。一般情况下"alter table"之类的语句才会使用表锁。

    行锁(row lock):行锁可以最大程度地支持并发读写,但数据库维护锁的开销会比较大。行锁是我们日常使用最多的锁策略,一般情况下MySQL中的行级锁由具体的存储引擎实现,而不是MySQL服务器层面去实现(表锁MySQL服务器层面会实现)。

    03 多版本并发控制(MVCC)

    MVCC(MultiVersion Concurrency Control),多版本并发控制。在MySQL的大多数事务引擎(如InnoDB)中,都不只是简单地实现了行级锁,否则会出现这样的情况:"数据A被某个用户更新期间(获取行级写锁),其他用户读取该条数据(获取读锁)都会被阻塞“。但现实情况显然不是这样,这是因为MySQL的存储引擎基于提升并发性能的考虑,通过MVCC数据多版本控制,做到了读写分离,从而实现不加锁读取数据进而做到了读写并行。

    以InnoDB存储引擎的MVCC实现为例:

    InnoDB的MVCC,是通过在每行记录后面保存两个隐藏的列来实现的。这两个列,一个保存了行的创建时间,一个保存了行的过期时间。当然它们存储的并不是实际的时间值,而是系统版本号。每开启一个新的事务,系统版本号都会自动递增;事务开始时刻的系统版本号会作为事务的版本号,用来和查询到的每行记录的版本号进行比较。

    MVCC在MySQL中实现所依赖的手段主要是:"undo log和read view"。

    • undo log :undo log 用于记录某行数据的多个版本的数据。

    • read view :用来判断当前版本数据的可见性

    undo log在后面讲述事务还会介绍到。关于MVCC的读写原理示意图如下:

    上图演示了MySQL InnoDB存储引擎,在REPEATABLE READ(可重复读)事务隔离级别下,通过额外保存两个系统版本号(行创建版本号、行删除版本号)实现MVCC,从而使得大多数读操作都可以不用再加读锁。这样的设计使得数据读取操作更加简单、性能更好。

    那么在MVCC模式下数据读取操作是如何保证数据读取正确的呢?以InnoDB为例,Select时会根据以下两个条件检查每行记录:

    • 只查找版本号小于或等于当前事务版本的数据行,这样可以确保事务读取的行要么是在事务开始前已经存在,要么是事务自身插入或者修过的。

    • 行的删除版本号要么未定义,要么大于当前事务版本号。这样可以确保事务读取到的行,在事务开始之前未被删除。

    只有符合上述两个条件的记录,才能返回作为查询的结果!以图中示范的逻辑为例,写请求将account变更为200的过程中,InnoDB会再插入一行新记录(account=200),并将当前系统版本号作为行创建版本号(createVersion=2),同时将当前系统版本号作为原来行的行删除版本号(deleteVersion=2),那么此时关于这条数据有两个版本的数据副本,具体如下:

    假如现在写操作还未结束,事务对其他用户暂不可见,按照Select检查条件只有accout=100的记录才符合条件,因此查询结果会返回account=100的记录!

    上述过程就是InnoDB存储引擎关于MVCC实现的基本原理,但是后面需要注意MVCC多版本并发控制的逻辑只能工作在“REPEATABLE READ(可重复读)和READ COMMITED(提交读)”两种事务隔离级别下。其他两个隔离级别都与MVCC不兼容,因为READ UNCOMMITED(未提交读)总是读取最新的数据行,而不是符合当前事务版本的数据行;而SERIALIZABLE则会对所有读取的行都加锁,也不符合MVCC的思想。

    MySQL事务


    前面在讲解了关于MySQL并发控制的过程中,也提到了事务相关的内容,接下来我们来更全面的梳理下关于事务的核心知识。

    相信大家在日常的开发过程中,都使用过数据库事务,对事务的特点也都能张口就来——ACID。那么事务内部到底是怎么实现的呢?在接下来的内容中,就来和大家具体聊一聊这个问题!

    01 事务概述

    数据库事务本身所要达成的效果主要体现在:"可靠性"以及"并发处理"这两个方面。

    • 可靠性:数据库要保证当insert或update操作抛出异常,或者数据库crash的时候要保障数据操作的前后一致。

    • 并发处理:说的是当多个并发请求过来,并且其中有一个请求是对数据进行修改操作,为了避免其他请求读到脏数据,需要对事务之间的读写进行隔离。

    实现MySQL数据库事务功能主要有三个技术,分别是日志文件(redo log和undo log)、锁技术及MVCC。

    02 redo log与undo log

    redo log与undo log是实现MySQL事务功能的核心技术。

    1)、redo log

    redo log叫做重做日志,是实现事务持久性的关键。redo log日志文件主要由2部分组成:重做日志缓冲(redo log buffer)、重做日志文件(redo log file)

    在MySql中为了提升数据库性能并不会把每次的修改都实时同步到磁盘,而是会先存到一个叫做“Boffer Pool”的缓冲池中,之后会再使用后台线程去实现缓冲池和磁盘之间的同步。

    如果采取这样的模式,可能会出现这样的问题:如果在数据还没来得及同步的情况下出现宕机或断电,那么就可能会丢失部分已提交事务的修改信息!而这种情况对于数据库软件来说是不可以接受的。

    所以redo log的主要作用就是用来记录已成功提交事务的修改信息,并且会在事务提交后实时将redo log持久化到磁盘,这样在系统重启之后就可以读取redo log来恢复最新的数据。

    接下来我们以前面SQL-A所开启的事务为例来演示redo log的具体是如何运行的,如下图所示:

    如上图所示,当修改一行记录的事务开启,MySQL存储引擎是把数据从磁盘读取到内存的缓冲池上进行修改,这个时候数据在内存中被修改后就与磁盘中的数据产生了差异,这种有差异的数据也被称之为“脏页”

    而一般存储引擎对于脏页的处理并不是每次生成脏页就即刻将脏页刷新回磁盘,而是通过后台线程“master thread”以大致每秒运行一次或每10秒运行一次的频率去刷新磁盘。在这种情况下,出现数据库宕机或断电等情况,那么尚未刷新回磁盘的数据就有可能丢失。

    而redo log日志的作用就是为了调和内存与磁盘的速度差异。当事务被提交时,存储引擎会首先将要修改的数据写入redo log,然后再去修改缓冲池中真正的数据页,并实时刷新一次数据同步。如果在这个过程中,数据库挂了,由于redo log物理日志文件已经记录了事务修改,所以在数据库重启后就可以根据redo log日志进行事务数据恢复。

    2)、undo log

    上面我们聊了redo log日志,它的作用主要是用来恢复数据,保障已提交事务的持久化特性。在MySQL中还有另外一种非常重要的日志类型undo log,又叫回滚日志,它主要是用于记录数据被修改前的信息,这与记录数据被修改后信息的redo log日志正好相反。

    undo log 主要记录事务修改之前版本的数据信息,假如由于系统错误或者rollback操作而回滚的话就可以根据undo log日志来将数据回滚到没被修改之前的状态。

    每次写入数据或者修改数据之前存储引擎都会将修改前的信息记录到undo log。

    03 事务的实现

    前面我们讲到了锁、多版本并发控制(MVCC)、重做日志(redo log)以及回滚日志(undo log),这些内容就是MySQL实现数据库事务的基础。从事务的四大特性来说,其对应关系主要体现如下:

    实际上事务原子性、持久性、隔离性的最终目的都是为了确保事务数据的一致性。而ACID只是个概念,事务的最终目的是要保障数据的可靠性和一致性。

    接下来我们再具体分析下事务ACID特性的实现原理。

    1)、原子性的实现

    ‍原子性,是指一个事务必须被视为不可分割的最小单位,一个事务中的所有操作要么全部执行成功、要么全部失败回滚,对一个事务来说不可能只执行其中的部分操作,这就是事务原子性的概念。

    而MySQL数据库实现原子性的主要是通过回滚操作来实现的。所谓回滚操作就是当发生错误异常或者显示地执行rollback语句时需要把数据还原到原先的模样,而这个过程就需要借助undo log来进行。具体规则如下:

    • 每条数据变更(insert/update/delete)操作都伴随着一条undo log的生成,并且回滚日志必须先于数据持久化到磁盘上;

    • 所谓的回滚就是根据undo log日志做逆向操作,比如delete的逆向操作为insert,insert的逆向操作为delete,update的逆向操作为update等;

    2)、持久性的实现

    ‍‍持久性,指的是事务一旦提交其所作的修改会永久地保存到数据库中,此时即使系统崩溃修改的数据也不会丢失。

    事务的持久性主要是通过redo log日志来实现的。redo log日志之所以能够弥补缓存同步所造成的数据差异,主要其具备以下特点:‍‍

    • redo log的存储是顺序的,而缓存同步则是随机操作;

    • 缓存同步是以数据页为单位,每次传输的数据大小大于redo log;

    关于redo log实现事务持久性的逻辑可参考本文前面关于redo log部分的内容!

    3)、隔离性的实现

    隔离性是事务ACID特性中最复杂的一个。在SQL标准里定义了四种隔离级别,每一种隔离级别都规定一个事务中的修改,那些是事务之间可见的,那些是不可见的。

    MySQL隔离级别有以下四种(级别由低到高):

    • READ UNCOMMITED (未提交读);

    • READ COMMITED (提交读)

    • REPEATABLE READ (可重复读)

    • SERIALIZABLE (可串行化)

    隔离级别越低,则数据库可以执行的并发度越高,但是实现的复杂度和开销也越大。只要彻底理解了隔离级别以及它的实现原理,就相当于理解了ACID中的事务隔离性。

    前面提到过,原子性、持久性、隔离性的目的最终都是为了实现数据的一致性,但隔离性与其它两个有所区别,原子性和持久性主要是为了保障数据的可靠性,比如做到宕机后的数据恢复,以及错误后的数据回滚。而隔离性的核心目标则是要管理多个并发读写请求的访问顺序,实现数据库数据的安全和高效访问,实质上就是一场数据的安全性与性能之间的权衡游戏。

    可靠性高的隔离级别,并发性能低(例如SERIALIZABLE隔离级别,因为所有的读写都会加锁);而可靠性低的,并发性能高(例如READ UNCOMMITED,因为读写完全不加锁)。

    接下来我们再分别分析下这四种隔离级别的特点:

    READ UNCOMMITTED

    在READ UNCOMMITTED隔离级别下,一个事务中的修改即使还没有提交,对其它事务也是可见,也就是说事务可以读取到未提交的数据。

    因为读不会添加锁,所以写操作在读的过程中修改数据的话会造成"脏读"。未提交读隔离级别读写示意图如下:

    如上图所示,写请求将account修改为200,此时事务未提交;但是读请求可以读取到未提交的事务数据account=200;随后写请求事务失败回滚account=100;那么此时读请求读取的account=200的数据就是脏数据。

    这种隔离级别的优点是读写并行、性能高;但是缺点是容易造成脏读。所以在MySQL数据库中一般情况下并不会采取此种隔离级别!

    READ COMMITED

    这种事务隔离级别也叫"不可重复读或提交读"。它的特点是一个事务在它提交之前的所有修改,其它事务都是不可见的;其它事务只能读到已提交的修改变化。

    这种隔离级别看起来很完美,也符合大部分逻辑场景,但该事务隔离级别会产生"不可重读""幻读"的问题。

    不可重读:是指一个事务内多次读取的相同行的数据,结果却不一样。例如事务A读取a行数据,而事务B此时修改了a行的数据并提交了事务,那么事务A在下一次读取a行数据时,发现和第一次不一样了!

    幻读:是指一个事务按照相同的查询条件检索数据,但是多次检索出的数据结果却不一样。例如事务A第一次以条件x=0检索数据获取了5条记录;此时事务B向表中插入了一条x=0的数据并提交了事务;那么事务A第二次再以条件x=0检索数据时,发现获取了6条记录!

    那么在READ COMMITED隔离级别下为什么会产生不可重复读和幻读的问题呢?

    实际上不可重复读事务隔离级别也采用了我们前面讲过的MVCC(多版本并发控制)机制。但在READ COMMITED隔离级别下的MVCC机制,会在每次select的时候都生成一个新的系统版本号,所以事务中每次select操作读到的不是一个副本而是不同的副本数据,所以在每次select之间,如果有其它事务更新并提交了我们读取的数据,那么就会产生不可重复读和幻读的现象。

    不可重复读产生的原因示意图如下:

    REPEATABLE READ

    事务隔离级别REPEATABLE READ,也叫可重复读,它是MySQL数据库的默认事务隔离级别。在这种事务隔离级别下,一个事务内的多次读取结果是一致的,这种隔离级别可以避免脏读、不可重复读等查询问题。

    这种事务隔离级别的实现手段主要是采用读写锁+MVCC机制。具体示意图如下:

    如上图所示,在该事务隔离级别下的MVCC机制,并不会在事务内每次查询都产生一个新的系统版本号,所以一个事务内的多次查询,数据副本都是一个,因此不会产生不可重复读问题。关于此隔离级别下MVCC更多的细节可参考前面内容!

    但是需要注意,此隔离级别解决了不可重复读的问题,但是并没有解决幻读的问题,所以如果事务A中存在条件查询,另外一个事务B在此期间新增或删除了该条件的数据并提交了事务,那么依然会造成事务A产生幻读。所以在使用MySQL时需要注意这个问题!

    SERIALIZABLE

    该隔离级别理解起来最简单,因为它读写请求都会加排他锁,所以不会造成任何数据不一致的问题,就是性能不高,所以采用此隔离级别的数据库很少!

    4)、一致性的实现

    一致性主要是指通过回滚、恢复以及在并发条件下的隔离性来实现数据库数据的一致!前面所讲述的原子性、持久性及隔离性最终就是为了实现一致性!

    MySQL存储引擎


    前面的内容我们分别讲述了MySQL并发控制和事务的内容,而实际上在并发控制和事务的具体细节都是依赖于MySql存储引擎来实现的。MySQL最重要、最与众不同的特性就是它的存储引擎架构,这种将数据处理和存储分离的架构设计使得用户在使用时可以根据性能、特性以及其它具体需求来选择相应的存储引擎。

    虽然如此,但绝大部分情况下使用MySQL数据库时选择的还是InnoDB存储引擎,不过这并不妨碍我们适当地了解下其它存储引擎的特点。接下来给大家简单总结下,具体如下:

    以上我们简单总结了MySQL各种存储引擎的大概特点及其大致适用的场景,但实际上除了InnoDB存储引擎外,在互联网业务中很少会看到其它存储引擎的身影。虽然MySQL内置了多种针对特定场景的存储引擎,但是它们大多都有相应的替代技术,例如日志类应用现在有Elasticsearch、而数仓类应用现在则有Hive、HBase等产品,至于内存数据库有MangoDB、Redis等NoSQL数据产品,所以能够给MySQL发挥的也只有InnoDB了!


    PS:以上就是本文的全部内容希望能够对你有所帮助!

    —————END—————

    参考文档:

    https://mp.weixin.qq.com/s/IvQWnts592KlDCnoXuP7DQ

    展开全文
  • 分布式事务解决方案

    千次阅读 2018-10-12 19:35:33
    2.分布式事务场景 1. 跨库事务 2. 分库分表 3.服务化 3.两阶段提交 & 三阶段提交 & paxos CAP + BASE 4. 典型的柔性事务方案 5. 场景的分布式事务解决方案 1. 基于XA协议的两阶段提交 2. ...

    目录

            1.本地事务

    2.分布式事务场景

    1. 跨库事务

    2. 分库分表

    3.服务化

    3.两阶段提交 & 三阶段提交 & paxos

    CAP + BASE

    4. 典型的柔性事务方案

    5. 场景的分布式事务解决方案

    1. 基于XA协议的两阶段提交

    2. 消息事务 + 最终一致性

    3. TCC 编程

    6. 柔性事务:最大努力通知

    7. TCC两阶段补偿型

    8. 方案对比


    1.本地事务

    Connection conn = ... //获取数据库连接
    conn.setAutoCommit(false); //开启事务
    try{
       //...执行增删改查sql
       conn.commit(); //提交事务
    }catch (Exception e) {
      conn.rollback();//事务回滚
    }finally{
       conn.close();//关闭链接
    }
     

    spring 提供了事务功能

    1. 配置事务管理器。spring提供了一个PlatformTransactionManager接口,其有2个重要的实现类: DataSourceTransactionManager:用于支持本地事务,事实上,其内部也是通过操作java.sql.Connection来开启、提交和回滚事务。

      JtaTransactionManager:用于支持分布式事务,其实现了JTA规范,使用XA协议进行两阶段提交。需要注意的是,这只是一个代理,我们需要为其提供一个JTA provider,一般是Java EE容器提供的事务协调器(Java EE server's transaction coordinator),也可以不依赖容器,配置一个本地的JTA provider。

    2. 在需要开启的事务的bean的方法上添加@Transitional注解

    2.分布式事务场景

    随着SOA和数据库的拆分,完成一个业务功能可能需要横跨多个服务,操作多个数据库,所以就涉及到了分布式事务:保证对于多个资源服务器的数据操作,要么全部成功,要么全部失败。分布式事务是为了保证不同资源服务器的数据一致性。比如下单操作: 库存系统-扣库存;订单系统-更新状态

    1. 跨库事务

    一个业务功能需要操作多个库

    2. 分库分表

    3.服务化

    所以,分布式场景中,无一例外的都直接或间接的操作了多个数据库。

    3.两阶段提交 & 三阶段提交 & paxos

    CAP + BASE

    柔性事务BASE

    1. 基本可用(Basically Available)

      指分布式系统在出现不可预知故障的时候,允许损失部分可用性。

    2. 软状态( Soft State)

      指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性。

    3. 最终一致( Eventual Consistency)

      强调的是所有的数据更新操作,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

    CAP原理

    1. Consistency:持久性存储+备份
    2. Availibility:可用性(切换)
    3. Partition Tolerance:数据一致性。网站规模总是快速扩张,所以P是必须的

    两阶段提交 & 三阶段提交 & paxos:分布式事务与一致性算法Paxos & raft & zab_followMyInclinations的专栏-CSDN博客

    4. 典型的柔性事务方案

    1. 最大努力通知(非可靠消息、定期校对)
    2. 可靠消息最终一致性(异步确保型)
    3.  TCC(两阶段型、补偿型)

    5. 场景的分布式事务解决方案

    1. 基于XA协议的两阶段提交

    XA是一个分布式事务协议,由Tuxedo提出。XA中大致分为两部分:事务管理器(TM)和本地资源管理器(RM)。其中本地资源管理器往往由数据库实现,比如Oracle、DB2这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

    XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也比较低。但是,XA也有致命的缺点,那就是性能不理想,特别是在交易下单链路,往往并发量很高,XA无法满足高并发场景。

    2. 消息事务 + 最终一致性

    所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个分布式事务里,保证要么本地操作成功成功并且对外发消息成功,要么两者都失败,开源的RocketMQ就支持这一特性。并不是所有的mq都支持事务消息,如kafka。此时可以使用独立消息服务、或者本地事务表,由独立的消息服务保证事务性、发送消息至消息队列。

    步骤

    1. A系统向消息中间件发送一条预备消息
    2. 消息中间件保存预备消息并返回成功
    3. A执行本地事务
    4. A发送提交消息给消息中间件

    • 如果步骤1错误,整个事务失败,不会执行A的本地操作
    • 如果步骤2错误,整个事务失败,不会执行A的本地操作
    • 如果步骤3错误,这时候需要回滚预备消息:A系统实现中间件的一个回调接口,由中间件不断执行这个接口,检查A事务是否执行成功,如果失败则回滚预备消息
    • 如果步骤4出错,A的本地事务成功,消息中间件通过回调接口,能够检查到A执行成功了,就可以对消息进行提交

    问题:如何知道A系统的本地事务是正在执行中还是执行失败(因为都为初始态),这个时间点如何确立,何时询问??虽然可以最终一致性,但是如果B系统一直执行不成功,依然会存在不一致的问题。

    3. TCC 编程

    所谓的TCC编程模式,也是两阶段提交的一个变种。TCC提供了一个编程框架,将整个业务逻辑分为三块:Try、Confirm和Cancel三个操作。以在线下单为例,Try阶段会去扣库存(还是锁定库存??),Confirm阶段则是去更新订单状态,如果更新订单失败,则进入Cancel阶段,会去恢复库存。

    6. 柔性事务:最大努力通知

    最大努力通知型适用于一些一致性时间敏感度低的业务,且被动方处理结果不影响主动方的处理结果。

    特点

    • 不可靠消息:业务活动主动方,在完成业务处理之后,想业务活动的被动方发送消息,直到通知N次后不再通知,允许消息丢失
    • 定期校对:业务活动的被动方,根据定时策略,向业务活动方查询(主动提供查询借款),恢复丢失的业务消息

    7. TCC两阶段补偿型

    TCC:try-confirm-cancel,主要是解决跨服务调用场景下的分布式事务问题。

    • try阶段:完成所有业务检查,预留业务资源(准隔离性)
    • confirm阶段:确认执行业务操作,不做任何业务检查,只使用try阶段预留的业务资源
    • cancel阶段:取消try阶段预留的业务资源

    补偿性事务:补偿是一个独立的支持ACID特性的本地事务,用于在逻辑上取消服务提供者上一个ACID事务造成的影响。confirm和cancel就是补偿事务,用于取消try阶段本地事务造成的影响

    与两阶段提交的区别:

    • 两阶段提交时资源层面上的分布式事务,强一致性,在两阶段提交的整个过程中,一直持有资源的锁(资源实际上一直都是被加锁的),如果有其他人需要操作这个两条记录,name必须等待锁释放
    • TCC是业务层面的分布式事务,最终一致性,不会持有资源的锁。

    与 DTP 事务模型的区别:

    • TCC 模型中主业务服务相当于DTP模型中的 application,TCC模型中的从业务服务相当于 DTP 模型中的 RM。DTP模型中,应用application操作多个资源管理器RM上的资源,而在TCC模型中,主业务服务操作多个从业务服务上的资源

    • TCC模型中,从业务提供的try-confirm-cancel接口相当于DTP模型中RM提供的 prepare、commit、rollback接口

    • DTC模型和TCC模型中都有一个事务管理器

      在DTP模型中,阶段1的(prepare)和阶段2的(commit、rollback),都是由TM进行调用的。

      在TCC模型中,阶段1的try接口是主业务服务调用(绿色箭头),阶段2的(confirm、cancel接口)是事务管理器TM调用(红色箭头)。这就是 TCC 分布式事务模型的二阶段异步化功能,从业务服务的第一阶段执行成功,主业务服务就可以提交完成,然后再由事务管理器框架异步的执行各从业务服务的第二阶段。这里牺牲了一定的隔离性和一致性的,但是提高了长事务的可用性

    TCC事务模型优缺点:

    • 优点:XA两阶段提交资源层面的,而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能低下问题。

    • 缺点:主业务服务和从业务服务都需要进行改造,从业务方改造成本更高。

    展开全文
  • 事务并发控制

    2016-12-28 16:15:47
    事务并发控制   9.1  信号量:依赖于程序员;不适当的使 用会死锁。分布式环境中很难 实现,必须保持信号量数据的绝对一 致性。   管程:编译器支持的编程语言结构。 编译器依靠共享内存实现信号量,...

     事务的并发控制

     

    9.1 

    信号量:依赖于程序员;不适当的使

    用会死锁。分布式环境中很难

    实现,必须保持信号量数据的绝对一

    致性。

     

    管程:编译器支持的编程语言结构。

    编译器依靠共享内存实现信号量,没

    有共享内存,就不能使用管程。

     

    对事务的调度要保证对共享数据

    的执行效果与其串行调度等价,

    服务器可通过串行访问数据项来

    实现串行等价。


     

    锁:串行结构的实现

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


     


    可串行性(化):两个事务的全部

    冲突操作对应相同的顺序执行。

    为保证可串行性,常用的三种并发

    控制方法:加锁、乐观并发控

    制、时间戳定序。

     

        1  加锁:

    当事务完成时解锁,当一数据项

    被加锁,则只有加锁的事务可访

    问它,其它事务或者等待锁被解

    开,或者在某种情况下共享锁。

    使用锁会导致死锁,即事务彼

    此等待解锁。

        2  乐观法:

    事务执行到提交前,在允许提交

    前,服务器完成一个检查,发现

    已完成的操作是否与相同数据项

    上的其它并发事务的操作发生

    冲突,若冲突,服务器终止它。

        3  时间戳定序:

    服务器记录读写每个数据项的最

    近时间,且对每一操作,要比较

    事务的时间戳和数据项的时间戳,

    以决定操作是否可立即执行、

    或被延迟、被拒绝。

    9.2  锁机制

     

    读    读                   不冲突

    读    写                   冲突

    写    写                   冲突

     

    1              读锁:其它可读,但不能写,

    有一个事务即加一个锁;

    2              写锁:写之前获得,不能读

    或写(再写);

     

    Lock  UnLock 操作

     

    锁的粒度越小,加锁就可以越精确,

    也就能实现更大的并行度。

    同时,锁的粒度越小,就需要更多的

    锁,这样开销也就越大,也

    就更容易导致死锁。

     

    9.3  乐观并发控制

     

    基础:在大多数应用中,两客户的事务访问同一数据项的可能性很小。


     

    三个阶段:

    1  读出阶段:

    每个事务修改的每个数据项都有一个试用性版本,所有的读操作都

    是在数据项的提交版本上完成的,不会读出“脏”数据。

        2  验证阶段:

    当接到Close Transaction请求,就检验事务是否存在对数据项上的操作与其它事务在同一数据项上的操作发生冲突,若验证通

    过,则事务提交,若验证失败,则要采用某种形式的冲突解决策略。

        3  写入阶段:

    若事务通过验证,它的试用性质版本中的所有修改记录将设置成永久的。

     

    事务验证即验证采用读/写冲突规则保证其特定事务的调度关于

    所有其他的重叠事务是串行等价的。

     

    事务验证:是基于一对事务Ti和Tj的操作间冲突的,事务Tj关

    于一个重叠事务Ti是可串行化的,那么它们的操作必须遵守以

    下规则。

     

     

    优点:避免了死锁,允许最大的并行度。

    缺点:有时会失效,所有的事务都必须退回重新运行一遍。

    在重负载的情况下,比较严重。

     

     

    9.4  时间戳定序

    每个事务开始时都被分配了一个唯一的时间戳,来自事务的申请

    就可以根据它们的时间戳获得一个全序

    服务器可以用自己的时钟来分配时间戳,或者它可采用当分配时

    间戳时就加1的计数器——“伪时间”。

     

    优点:不会出现死锁。

    缺点:在于实现的复杂性,这将导致降低性能。



      硬件、系统和语言对并发支持的总结


    第十章  分布式事务

     

    事务的ACID特性:

     

    原子性

    一致性

    独立性

    持久性

     

    分布式事务:其活动涉及多个服务器的事务;

    嵌套事务:间接涉及多个服务器的客户事务;

     

    每个服务器对其本地数据实行本地并发控制,以保证事务在本地可串行,分布式事务必须在全局可串行。

    在某些情况下,事务在本地服务器上是串行的,但同时可以发生不同服务器间的依赖循环,从而导致死锁。

     

    分布式事务的协调者

    事务的第一个服务器成为事务的协调者,负责终止或提交事务,以

    及增加其他被称为参与者的服务器,协调者管理着一个参与者表列,

    而每个参与者都记录了协调者服务器的标识。

     

     

    原子提交协议:

     

     

    两阶段提交协议


     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     



    两阶段提交协议中的超时

    若协调者失败了,则参与者不能获得应答直到协调者重新启动,这

    会导致参与者处于不确定状态的额外延迟。

     

    当客户发送了close transaction给协调者,参与者只能检测到这种

    情况:长时间没有特定事务的请求。

    由于在这个时期没有作出决定,参与者可在一段时间后单向决定

    终止。

     

    事务实现中的问题:

    (1) 预读写

    如果一个事务对一个数据进行读操作,而这个数据正在被其他将要

    退出的事务操作,这时预读问题就发生了。

     

     

     

    如果一个事务对一个数据进行写操作,而这个数据正在被另一个事务操作,预写问题。

     

    涉及到独立事务的相互作用。

    事务管理服务采用延迟执行就可以避免这些问题的发生。

    延迟执行使得正在被事务操作的数据不能被其他事务读写,直到当

    前事务进入提交阶段或者中途退出。

     

    延迟会降低系统的性能。

     

    (2) 中途退出(domino effect)

    如果其他事务看到了与退出的事务有关的结果,这个事务的

    退出可能遭受domino effect。

     

    任何以预写的数据为执行基础的事务在预写的事务中途退出后,也都必须退出。

     

    (3) 保证恢复能力

    如果另一个未完成的提交请求涉及到相同的数据,则应延迟当前的提交。

     

    暂时拷贝可以保存在本地的易失存储器中,如果一直不进入提交阶

    段,则删除暂时拷贝。如果进入提交阶段,则把暂时拷贝复制到永

    久的不易丢失的存储器中。

     

     

     

     

    分布式事务的并发控制

    (1)分布式事务的锁机制

    由于服务器彼此独立地设置它们的锁,有可能不同服务器将不同的次序加于事务之上,在这种情况下,这些不同次序会导致事务间的循环依赖,出现分布式死锁情况。

    在嵌套事务中,为了避免层次间的潜在冲突,父事务不允许与它们的子事务并发执行。嵌套事务从它们的祖先那里继承锁。

    对一个获得数据资源读锁的嵌套事务,该数据资源写锁的持有者必须是它的祖先。当一个嵌套事务提交时,它的锁被其父母继承。当嵌套事务中止时,它的锁被解除。

     

    (2)分布式事务的时间戳定序

    为实现在所有服务器上的相同次序,服务器必须在它们的时间戳次序上达成一致。

    在分布式系统中,要求每一个事务可以分配到环境中唯一的时间戳。该事务在调用其他服务器的资源时,同样也把该时间戳发送给相应的服务器,以使该服务器对事务进行合理的调度。分布式系统中的服务器共同负责保证它们按与串行效果等价的方式完成。

    但是时间戳的分配还存在着一致性的问题。一个分布式系统包含很多不同的地点和个别的计算机系统,每一个地点和系统都有其各自的本地时间,各处系统的时钟也会偏移。因此各个服务器间的时钟可能不同步,从而造成时间戳分配的不一致性。为了保证事务次序同在实际时间中开始的次序一致,通常采用同步本地物理时钟的方法。

     

     

    (3)分布式事务的乐观并发控制

    服务器在验证开始时,分配事务号,事务根据事务号的次序排序。分布式事务被一组相互独立的服务器集验证,每个服务器验证访问其数据项的事务。所有服务器的验证发生在两阶段提交协议的第一阶段。

     

     

    分布式死锁

    超时 解除死锁。

    寻找事务等待图中的环路来实现。

     

    死锁检测方案

     

    伪死锁

     

    带复制数据的事务

    事务服务器上的数据项可被复制,以提高可用性和其他性能。

     

    单副本可串行性:事务在各客户的复制数据项上执行的效果仿佛是

    他们一次只对单个数据项执行。

     

    Read one/ write all

    读操作只由单个复制管理者执行,而写操作则由所有的复制管理者

    执行。

    它不是一个实用的方案,因为当某些复制管理者失效时,它无法运行,设计有效副本方案,用来允许一些复制管理者暂时失效。

    其策略是:客户的请求可由任一有效复制者执行,而客户的更新请求必须由包含该数据项副本的组中所有有效复制者执行。

     

    展开全文
  • 文章目录1、事务简介2、并发控制2.1 并发执行2.2 可串行化调度(Serializable)3、锁协议3.1 封锁3.2 封锁协议3.2.1 一级封锁协议3.2.2 二级封锁协议3.2.3 三级封锁协议4、活锁和死锁4.1 活锁4.2 死锁4.2.1 死锁的预防...

    1、事务简介

      事务(Transaction)是指用户定义的一个数据库操作序列,这些操作要门全做,要么全都不做,是一个不可分割的整体。 我想,99%的在阐述事务的概念时都会用银行转账的例子,那么我也用这个例子来阐述,因为它更容易理解。在银行转账业务中,顾客认为支票帐户向存储用户的资金转账就好似一个事务,这个动作要么全部执行,要么什么都不执行,如果转出用户在转账过程中他的金额成功减少了,但是收款方并没有收到,如果出现问题就会导致A的白花花的银子确实减少了,但是B的帐户确没有多出的银子,这就出现了无缘无故A的前少了的情况。因此在数据库系统中对事务的控制非常重要。
      事务分为隐形事务和显示事务,DBMS按照默认规定将一条sql语句认为是一条隐式事务;而显式事务需要通过sql语句显式指定。
      一般来讲,事务具有以下4个特征,简称为ACID:

    • 原子性(Atomicity): 指事务是数据库的逻辑工作单位,事务中的所有操作,要么全做,要么全部不做。
    • 一致性(consistency): 当数据库中只包含成功事务的提交结果时,就说数据库处于一致性状态。什么是不一致的状态呢?也就是说在执行事务时,假如由于断电等原因,事务中的一些操作已经被写入物理数据库,而一些操作没有被写入,那么此时就处于不一致的状态。
    • 隔离性(Isolation): 指数据库中一个事务在执行过程中不能受到其他事务的干扰,该事务的内部操作及数据对象的使用对其他事务是隔离的。
    • 持续性(Durability): 指事务一旦提交,对数据库所做的更改就是永久的,这是保证数据库数据安全的保证。

    2、并发控制

      在数据库中,串行执行的方式就意味着,一个事务必须等到另一个事务结束后才能执行,这种执行方式使数据库的系统资源得不到更好地发挥不能发挥数据库共享资源的特点。

    • 2.1 并发执行

      当使用并发的方式执行事务时,可能存在不同的事务同时存取同一个数据对象的情况,这样就可能造成,读取或写入不正确的数据,破坏数据库的一致性。因此,必须提供并发的控制机制,来防止这些情况的发生,并发控制是DBMS性能的重要标志。一般来讲并发可能会发生3种情况导致数据库的一致性被破坏,分别为:丢失修改,不可重复读,读 “脏“数据。

    • 丢失修改(Lost Update): 指两个事务T1和T2读入同一数据并进行修该,T2提交的结果破坏了T1提交的修改,我们用一个图来说明
      在这里插入图片描述
      T1, T2执行后,我们希望的结果明明是让A=8,可是这个时候A=9,因此可以看到数据的一致性被破坏了。
    • 不可重复读(Non-Repetable Read): 事务T1读取数据后,T2对数据进行更新操作,使得T1无法再现之前的结果。具体包括3种情况:
      (1)T1读取某个数据后,T2进行修改,当T1再次读数据与前一次是不同的结果;
      (2)T1读取数据后,T2删除其中的部分记录,当T1再次读取时,发现某些记录已经消失了,也叫做 ”虚读“。
      (3)T1读取数据后,T2对数据中插入了某些记录,当T1再次读取时,发现多了一些记录,这也叫 ”幻读“。
      下图阐述了第一种情况:
      在这里插入图片描述
    • 读 ”脏”数据(Dirty Read): 指一个事务读取了某个失败事务运行过程中的数据。如下图
      在这里插入图片描述
    • 2.2 可串行化调度(Serializable)

      DBMS要控制事务地并发执行,保证数据库的一致性,那么需要怎么样的调度方式才能做到正确呢?当且仅当执行结果与按照某一顺序串行地执行这些事务时的结果相同,那么称这种调度是可串行化的调度。
      简单地说就是如果有两个事务T1和T2,当它们并发执行的时候,其结果和从T1到T2串行执行或者从T2到T1串行执行的结果相同则说明该并发的调度是正确的调度。

    3、锁协议

      对于数据库的并发控制技术有封锁、时间戳、乐观控制法。目前大多DBMS一般都采用了锁的技术。

    • 3.1 封锁

      锁的机制是确保事务并发调度是可串行化的一种常用技术,所谓锁就是让事务对数据对象具有一定的控制,一般分为3步:
    (1)申请加锁,事务在对数据对象进行操作前对数据提出加锁的请求。
    (2)获得锁,当条件满足时,系统允许事务对该数据对象进行加锁,从而对数据获得控制权。
    (3)释放锁,操作完成后,事务放弃对数据对象的控制权。
      基本的锁类型有两种:排他锁(Exclusive Lock)共享锁(Share Locks)。排他锁又叫写锁,简称X锁,如果T获得数据对象的X锁,则只允许T读取和修改此数据对象,其他事务不能对此数据对象加任何类型的锁,直到T释放X锁;共享锁又叫读锁,简称为S锁,如果一个事务T获得数据对象的共享锁,则允许T读取数据,其他事务只能再对这个数据对象加S锁,而不能加X锁,直到T释放该数据对象上的S锁。

    • 3.2 封锁协议

      通过封锁来达到并发控制的目的就必须要选择合适的锁,以及遵守一定的规则,什么时候申请锁,锁的时间,释放时间等,这些就叫锁的协议。

    • 3.2.1 一级封锁协议

      事务T在修改数据对象之前先对数据对象加X锁,直到事务结束(commit或rollback)才释放。 一级封锁协议可以防止丢失修改,并保证事务T是可恢复的。在这种协议之下如果另一个事务不需要修改数据,则不需要加锁,因此这种协议,不能保证可重复读和不读“脏”数据。我们以丢失修改中的例子来描述一下一级封锁协议过程:
    在这里插入图片描述

    • 3.2.2 二级封锁协议

      在一级封锁协议的基础上增加T对要读取的数据对象加S锁,读完后释放S锁。 二级封锁协议不仅可以防止丢失修改,还可以防止读“脏”数据。在二级封锁协议中,由于事务T读完数据后立即释放S锁,因此它不能保证可重复读数据。以下为二级封锁协议的过程:
    在这里插入图片描述

    • 3.2.3 三级封锁协议

      一级封锁协议加上事务T对要读取的数据对象加S锁,直到事务结束才释放。 三级封锁协议可满足,防止丢失修改,防止读“脏”数据,保证可重复读。
    在这里插入图片描述
      这三级封锁协议区别在于哪些操作需要申请锁以及何时释放锁。随着锁的协议地身高可以避免跟多不一致的情况出现。但是数据对象被封锁的时间越长,并发执行的效率就越低。这里我们再说说两段封锁协议, 两段封锁协议是指,所有事务必须分为两个阶段对数据进行加锁和解锁,其一:在对任何数据对象进行读、写操作之前,事务首先要获得对该数据对象的封锁;其二:在释放封锁之后,事务不再申请和获得任何锁。简单地说就是,事务在执行过程中不允许加锁和解锁交叉执行,加锁动作都是在所有释放锁的动作前。

    4、活锁和死锁

      锁的机制可以解决并发操作带来的数据库不一致问题,同样锁也会带来一些问题,这就是活锁和死锁。

    • 4.1 活锁

      当事务T1对数据对象加锁后,T2又申请对该数据对象加锁,这是T3也请求对该数据对象加锁,这时它们都在等待T1释放对该数据对象的锁。等到T1释放了该数据对象的锁后,该锁被T3持有,于是乎,T2又继续等待。这时又有T4,T5…又申请对该数据对象加锁。因此T2可能永远在等待,这就是活锁。避免活锁的简单方法就是使用队列,谁先来谁持有。

    • 4.2 死锁

      当T1事务持有某数据对象d1的锁的时候,T2事务也持有数据对象d2的锁,此时T1又申请持有d2的锁,这时T2又申请持有d1的锁,因此你在等我,我在等你两个事务永远也不能结束,这样就形成了死锁。在数据库中解决死锁有两种思路:预防死锁和死锁发生后的诊断和解除。

    • 4.2.1 死锁的预防

      我们知道死锁产生的原因就是多个事务已经封锁了某些数据对象,但是又申请了其他已经被封锁的数据对象而形成的循环。预防死锁一般有两种方法,但都是在操作系统中比较广泛采用的方法,但是在数据库中并不常用。但是我还是说一下,通常有两种策略:一次封锁法和顺序封锁法。
      所谓一次封锁法就是必须一次性将所要用到的数据对象全部封锁,否则就不能执行。例如T1对数据对象d1和d2全部加锁,另一个T2若想要加锁就必须等到T1执行完毕才能持有锁因此就不会出现死锁。但是这样有缺点,其一,如果一次性封锁需要用到的数据对象就一定会扩大锁的范围和时间,这样就会降低系统的并发效率;其二,由于数据库中的数据不断变化,原来不需要加锁的数据可能在执行过程中就变成需要加锁的对象。因此只能再次扩大范围,这样就进一步降低了并发性。
      顺序加锁法就是预先对数据对象规定一个加锁的顺序,所有的事务都按照这个顺序对数据对象加锁。但是这样也有问题,其一,数据库中的数据对象非常多,而且不断变化,维护可变性太强的数据成本高难以实现;其二,事务的加锁请求随着事务的执行而动态决定,很难维护这样的顺序。

    • 4.2.2 死锁的诊断和解除

      死锁的诊断一般使用超时法和等待图法,这里面与操作系统中所采用的策略类似。
      所谓超时法就是如果一个事务的等待时间超过了规定的时间,就认为发生了死锁。超时法的优点是简单容易实现。但是缺点就是容易产生误判,如果事务是由于客官的原因而造成的等待时间过长,就会被系统认定为发生了死锁。如果将时间间隔设置太长的话,就会导致无法及时处理死锁。
      等待图法就是用事务等待图动态反映所有事务的等待情况,等待事务图是一个有向图,图的结点为一个事务,有向边代表等待关系,如下图:
    在这里插入图片描述
    左边显示的就是一个没有死锁的无环等待图,从图中可以看到T1等待T2,T1等待T3,而T3又等待T2,因此当T2的锁释放的时候,T1和T3就能拥有锁。对于右边不仅有大环还有小环可以看到T1和T2和T4之间形成了环,这样就是死锁了。
      数据库管理系统的并发控制系统会周期性地生成事务等待图,检测事务是否有环,如果发生环路就形成了死锁。一旦产生死锁就要解决,一般解决的思路就是选择一个处理代价最小的事务rollback。

    5、锁的粒度

      加锁对象的大小就称为锁的粒度。加锁的对象可以是逻辑单元也可以是屋里单元,总之在并发系统中,可能会产生资源竞争的都可以加锁。例如关系数据库中的属性,元组,表。或者屋里单元中的page,块等。
      锁的粒度和系统的并发程度密切相关。锁的粒度越大,系统开销就越小同时系统的并发程度就越低;相反,锁的粒度越小,系统开销就越大,同时并发程度就越高。因此一个好的系统应该提供多粒度锁 来支持不同事务的选择。选择加锁的粒度时应该同时考虑系统的开销和并发程度。

    展开全文
  • MyBatis面试题(2020最新版)

    万次阅读 多人点赞 2019-09-24 16:40:33
    1、 创建SqlSessionFactory 2、 通过SqlSessionFactory创建SqlSession 3、 通过sqlsession执行数据库操作 4、 调用session.commit()提交事务 5、 调用session.close()关闭会话 请说说MyBatis的工作原理 在学习 ...
  • 数据库——事务并发控制

    千次阅读 2019-05-22 09:04:34
    2.1事务并发执行 2.2并发执行导致的问题 2.2.1丢失修改 2.2.2读“脏”数据 2.2.3不可重复读 三、封锁 3.1基本锁类型 3.2封锁协议 3.2.1一级封锁协议 3.2.2二级封锁协议 3.2.3三级封锁协议 3.3活锁与...
  • 并发事务管理注意事项

    千次阅读 2017-06-07 18:03:35
    如果开发的系统是高并发的话,声明式事务管理尽量使用注解的方式:@Transactional使用注解控制事务方法的优点: * 1:开发团队达成一致约定,明确标注事务方法的编程风格 * 2:保证事务方法的执行时间尽可能短,...
  • MySQL数据库事务并发问题的解决

    千次阅读 2019-05-16 16:29:35
    常见的关系型数据库有MySQL、Oracle、SQLServer等,其中MySQL成为目前互联网企业应用...接下来小编对数据库事务以及并发问题的解决进行分析和总结: 预计阅读时间:5分钟 什么是事务 事务是一条或多条数据库操作语...
  • 并发控制

    2020-05-02 15:32:37
    目录并发控制并发控制概述丢失修改不可重复读脏读封锁三级封锁协议一级封锁协议二级封锁协议三级封锁...并发操作带来的数据不一致性,所有的问题都指的是在一次事务内,两次事务间就不管了 丢失修改 不可重复读 ...
  • RocketMQ

    万次阅读 多人点赞 2019-07-31 19:17:34
    可以执行多次上面消费者的main方法,也就是启动多个这样的消费者,因为在一个群组里,消息每次只会发送给群组里的一个成员,所以假设有100条消息,启动了两个同一群组的消费者,那么每个消费者各消费50条消息。...
  • MySQL 面试题

    万次阅读 多人点赞 2019-09-02 16:03:33
    事务和隔离级别。 因为 MySQL 还会有部分内容和运维相关度比较高,所以本文我们分成两部分【开发】【运维】两部分。 对于【开发】部分,我们需要掌握。 对于【运维】部分,更多考验开发的知识储备情况,当然能回答...
  • mysql面试题

    千次阅读 2019-09-23 12:28:36
    最全MySQL面试题和答案 ...2.innodb是支持事务的存储引擎,合于插入和更新操作比较多的应用,设计合理的话是行锁(最大区别就在锁的级别上),适合大数据,大并发。 数据表类型有哪些     ...
  • Spring

    千次阅读 多人点赞 2020-02-04 17:41:35
    Spring里的声明式事务的做法和优点? 依赖注入? 文章目录1.Spring1.1搭建 Spring 运行时环境1.2HelloWorld2.spring IOC&DI3.Spring AOP4.Spring事务什么叫延迟加载? 1.Spring 1.1搭建 Spring 运行时...
  • JAVA面试笔记

    千次阅读 多人点赞 2019-03-07 17:52:40
    ​ 隔离级别是指若干个并发事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量: TransactionDefinition.ISOLATION_DEFAULT:这是默认值,表示使用底层数据库的默认隔离级别...
  • 数据库面试

    千次阅读 多人点赞 2019-02-13 09:03:42
    隔离性Isolation,指多个用户并发访问数据库时,数据库为每个用户执行事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。事务的隔离级别在后文中介绍。 持久性Durability,指一个事务一旦提交并...
  • 消息中间件MQ与RabbitMQ面试题(2020最新版)

    万次阅读 多人点赞 2020-03-01 11:11:21
    MQ的优点消息队列有什么优缺点?RabbitMQ有什么优缺点?你们公司生产环境用的是什么消息中间件?Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?MQ 有哪些常见问题?如何解决这些问题?什么是RabbitMQ?...
  • Redis面试题集

    千次阅读 多人点赞 2019-09-16 10:19:31
    缓存击穿: 是指一个key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。 发生场景:某一个商品爆款...
  • 测试开发笔记

    万次阅读 多人点赞 2019-11-14 17:11:58
    1、发布一个下载地址 2、用户进行软件下载并使用 回归测试: 回归测试可以发生在任何一个阶段 分为完全回归和选择回归 回归范围 回归分类 特点 优点 缺点 适用范围 完全回归 完全重复法 每次回归测试都要执行全部...
  • 【数据库学习】数据库总结

    万次阅读 多人点赞 2018-07-26 13:26:41
    数据库的查询,大量并发的时候可能最浪费时间的是connect和close。 数据库的优势是体现的大量数据的查询、统计以及并发读写,不是在速度上。 2)数据库数据特点 永久存储、有组织、可共享。 (数据的最小存取单位是...
  • J2EE

    千次阅读 多人点赞 2019-08-08 15:25:13
    J2EE 是针对 Web Service、业务对象、数据访问和消息报...二是使服务器能控制构件的生命周期和其他资源,以便能够处理扩展、并发事务处理管理和安全性问题。 表示层 J2EE 客户端可以基于 Web,也可以基于 Ja...
  • 事务(Transaction)是并发控制的单位,是用户定义的一个操作序列。这些操作要么都做,要么都不做,是一个不可分割的工作单位。 通过事务,SQL Server能将逻辑相关的一组操作绑定在一起,以便服务器保持数据的完整...
  • 在单处理机系统中,事务的并行执行实际上是这些并行事务的并行操作轮流交叉运行。 11.1 并发控制概述 事务并发控制的基本单位。 并发控制的目的:保证事务的隔离性和一致性 任务: 对并发操作进行正确调度 ...
  • sqlserver并发处理,锁和事务

    千次阅读 2014-03-07 12:01:41
    MS-SQLSERVER 使用锁在多个同时在数据库内执行修改的用户间实现悲观并发控制  三 锁的粒度  锁粒度是被封锁目标的大小,封锁粒度小则并发性高,但开销大,封锁粒度大则并发性低但开销小  SQL Server支持...
  • 软件测试面试题汇总

    万次阅读 多人点赞 2018-09-27 12:31:09
    在lordrunner中,如何进行并发的测试?集合点失败了会怎么样? .................................. 6 12、使用QTP做功能测试,录制脚本的时候,要验证多个用户的登录情况/查询情况,如何操作? ......... 6 ...
  • JavaWeb

    千次阅读 多人点赞 2017-12-26 09:09:24
    Node.js可以理解为时一门后端脚本语言,使用了和JavaScript相同的语法,会使用JavaScript的程序员能很快的上手node.js、nodejs在处理高并发性能卓越,目前很多公司在使用nodejs作为后端数据服务和前端开发的中间层 ...
  • 在讨论数据库并发之前我们先引入事务的概念: 数据库事务通常包含了一个序列的对数据库的读/写操作(一个单元的一系列SQL语句的集合)。 我们引入事务无非是为了实现以下两个目的: 为数据库操作序列提供一个从失败...
  • 《数据库原理》— 数据库系统概论第五版习题解析

    万次阅读 多人点赞 2017-05-29 14:57:48
    因为 DBMS 在数据库建立、运用和维护时对数据库进行统一的管理和控制,包括数据的完整性、安全性、多用户并发控制、故障恢复等,都由 DBMS 执行。总之,使用数据库系统的优点是很多的,既便于数据的集中管理,...
  • 优点: 它提供了一个方便,以自动化的方式来保持一致性,像上述的案例。这意味着,每一个动作只能执行一次,它保证用户或服务器过程中看到的是最新状态。 它需要很少的工作来设置。 由于其乐观的天性,速度...
  • Tomcat面试题+http面试题+Nginx面试题+常见面试题

    千次阅读 多人点赞 2019-12-12 15:04:43
    可以是一块盘和N个盘组合 其优点读写快,是RAID中最好的 缺点:没有冗余,一块坏了数据就全没有了 RAID 1,只能2块盘,盘的大小可以不一样,以小的为准 10G+10G只有10G,另一个做备份。它有100%的冗余,缺点:浪费...
  • 关系数据库——并发控制

    千次阅读 多人点赞 2019-12-02 14:04:03
    并发控制 多用户数据库:允许多个用户同时...单处理机系统中,事务并发执行实际上是这些并行事务的并行操作轮流交叉运行(不是真正的并发,但是提高了系统效率) 3.同时并发方式: 多处理机系统中,每个处理机...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 67,241
精华内容 26,896
关键字:

并发执行事务的优点