事务管理

概述： 事务是由一系列语句构成的逻辑工作单元。事务和存储过程等批处理有一定程度上的相似之处， 通常都是为了完成一定业务逻辑而将一条或者多条语句“封装”起来，使它们与其他语句之间出现一个逻辑上的边界，并形成相对独立的一个工作单元。 当使用事务修改多个数据表时，如果在处理的过程中出现了某种错误，例如系统死机或突然断电等情况，则返回结果是数据全部没有被保存。 因为事务处理的结果只有两种：一种是在事务处理的过程中，如果发生了某种错误则整个事务全部回滚，使所有对数据的修改全部撤销，事务对数据库的操作是单步执行的，当遇到错误时可以随时回滚； 另一种是如果没有发生任何错误且每一步的执行都成功，则整个事务全部被提交。从而可以看出，有效地使用事务不但可以提高数据的安全性，还可以增强数据的处理效率。 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你既需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！ 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。 事务用来管理 insert,update,delete 语句 事务包含四种重要的属性，被统称为ACID

数据：描述事物的符号记录。 数据库：长期存储在计算机内、有组织的、可共享的统一管理的数据集合。 数据库系统：带有数据库的计算机应用系统，因此不仅包括数据库本身，即实际存储在计算机中的数据，还包括相应的硬件支撑环境、软件系统和各类相关人员。也就是说，数据库系统是一个由使用和维护人员、软硬件和数据资源等构成的完整计算机应用系统。 数据库管理系统：是位于用户与操作系统之间的具有数据定义、数据操纵、数据库的运行管理、数据库的建立和维护功能的一层数据管理软件。 外模式：用户模式，是数据库用户和数据库系统的接口，是数据库用户的数据视图,是数据库用户可以看见和使用的局部数据的逻辑结构和特征的描述，是与某一应用有关的数据的逻辑表示。外模式是保证数据库安全的重要措施。每个用户只能看见和访问所对应的外模式中的数据，而数据库中的其他数据均不可见。 模式：又可细分为概念模式和逻辑模式，是所有数据库用户的公共数据视图，是数据库中全部数据的逻辑结构和特征的描述。 内模式：又称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式。 外模式/模式映像：对于每一个外模式，数据库系统都一个外模式/模式映像，它定义了该外模式与模式之间的对应关系。如果数据库的模式改变，则对外模式/模式映像作相应改变，使外模式保持不变，从而不必修改外模式的应用程序，保证了数据与程序的逻辑独立性。 模式/内模式映像

目录 什么是MVCC？ MVCC-插入 MVCC-删除 MVCC-修改 MVCC-查询 Undo log Redo log 什么是MVCC？ Multi Version Concurrency Control (多版本并发控制) 并发访问(读或写)数据库时，对事务内正在处理的数据做多版本管理。以实现写操作堵塞的同时，依然可以进行读操作。 MVCC-插入 插入规则：在数据行版本号列保存当前事务ID。 MVCC-删除 删除规则：将删除版本号列更新为当前事务ID。 MVCC-修改 修改规则：现将命中的数据行copy，将原数据的删除版本号设置为当前事务ID（33）。 MVCC-查询 查询规则： 1. 查找数据行版本小于或等于当前事务版本的数据行。这样可以确保事务读取的行，要么是在事务开始之前就存在的，要么是事务自身插入或修改过的； 2. 查找删除版本号要么为NULL，要么大于当前事务版本号的数据行。这样可以确保查询出来的记录在事务开启前没有被删除。 Undo log Undo意为取消，以撤销操作为目的，返回指定某个状态的操作。 Undo log指事务开始之前，在操作任何数据之前,首先将需操作的数据备份到一个地方 (Undo Log)。 UndoLog是为了实现事务的原子性而出现的产物。 Undo Log实现了事务的原子性： 事务处理过程中如果出现了错误或者用户执行了 ROLLBACK语句

本文概要 本文分两部分， 第一部分概念介绍，重在理解。 第二部分通过MySQL Innodb中的具体实现，加深相关知识的印象。 本文的原意是一篇个人学习笔记，为了避免成为草草记录一下的流水账，尝试从给人介绍的角度开写。但在整理的过程中，越来越感觉力不从心，一是细节太多了，原以为足够了解的一个小知识点下可能隐藏了很多细节；二是内容与范围的取舍，既想有点技术性避免空谈，又不想陷入枯燥冗长的小细节描述。几番折腾，目前的想法把坑填上，能写完就不错了，你读起来有不顺或错误的地方请见谅，欢迎反馈。 1. 概念与理解 Redo与undo并非是相互的逆操作，而是能配合起来使用的两种机制。 说是两种机制，其实都是日志记录，不同的是redo记录以顺序附加的形式记录新值，如某条记录<T,X,V>，表示事物T将新值V存储到 数据库 元素X，新值可以保证重做； 而Undo记录通常以随机操作的形式记录旧值，如某条记录<T1,Y,9>，表示事物T1对Y进行了修改，修改前Y的值是9，旧值能用于撤销，也能供其他事务读取。 Redo用来保证事务的原子性和持久性，Undo能保证事务的一致性，两者也是系统恢复的基础前提。 1.1 Redo 一个事务从开始到结束，要么提交完成，要么中止，具有原子性。而反映在redo日志中可能需要若干条记录来保证，如： <T0 start> <T0,A,500> <T0,B,500> <T0

摘自： https://www.cnblogs.com/iceggboom/p/12144570.html 分布式事务框架-seata初识 一、事务与分布式事务 事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。 那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。 二、介绍 Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。 三、架构 Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。 Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。 Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。 Config

user=LF password=LF jdbcUrl=jdbc:oracle:thin:@localhost:1521:orcl driverClass=oracle.jdbc.driver.OracleDriver initialPoolSize=15 maxPoolSize=30 minPoolSize=5 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:tx="http://www.springframework.org/schema/tx" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http:

单点数据库 数据库往往是系统中的性能瓶颈，所以通常在系统设计中会引入各种各样的缓存机制，以避免频繁访问数据库。另外，数据库由于其重要性，高可用要求也是避免不了的，因为一旦数据库挂了基本上整个系统也就不能使用了。 而以上这些常见问题都是单点数据库带来的限制，为了解决这些问题，达到高性能、高可用的目的，我们就需要在系统架构设计中采用数据库集群方案。 性能测试 既然单点数据库存在性能问题，那么有没有实际数据呢？下面我们就来对单点数据库进行一个性能测试，看看其并发极限大概是多少。我这里使用了一台2核2G的云服务，mysql版本为8.0.18。 mysql自带了一个性能测试工具：mysqlslap，我们可以使用该工具进行测试，具体的测试参数如下： [root@localhost ~]# mysqlslap -hlocalhost -uroot -pyour_password -P3306 --concurrency=500 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=500 主要参数说明： 参数 说明 --concurrency 并发数量

丢失更新 ：两个事务同时更新一行数据，最后一个事务的更新会覆盖掉第一个事务的更新，从而导致第一个事务更新的数据丢失，这是由于没有加锁造成的； 1. 脏读 ：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。 e.g. 1.Mary的原工资为1000, 财务人员将Mary的工资改为了8000(但未提交事务) 2.Mary读取自己的工资 ,发现自己的工资变为了8000，欢天喜地！ 3.而财务发现操作有误，回滚了事务,Mary的工资又变为了1000 像这样,Mary记取的工资数8000是一个脏数据。 2. 不可重复读 ：是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。 e.g. 1.在事务1中，Mary 读取了自己的工资为1000,操作并没有完成 2.在事务2中，这时财务人员修改了Mary的工资为2000,并提交了事务. 3.在事务1中，Mary 再次读取自己的工资时，工资变为了2000 解决办法：如果只有在修改事务完全提交之后才可以读取数据，则可以避免该问题。 3. 幻读 :

TRANSACTION（事务隔离级别） 在说明事务隔离级别之前先说一下 脏读 、 不可重复读 、 幻读 这三个概念。 脏读： 一个事务读取到另一事务未提交的更新新据。当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有 提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另 外一个事务读到的这个数据是脏数据，依据脏数据所做的操作也可能是不正确的。 不可重复读： 在同一事务中，多次读取同一数据返回的结果有所不同。换句话说就是，后续读取可以读到另一事务已提交的 更新数据。相反，“可重复读”在同一事务中多次读取数据时，能够保证所读数据一样，也就是，后续读取不能读到另一事务 已提交的更新数据。 幻读： 事务T1执行一次查询，然后事务T2新插入一行记录，这行记录恰好可以满足T1所使用的查询的条件。然后T1又使用相同 的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”，因为对T1来说这一行就像突然 出现的一样。 1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。 每种数据库的默认隔离级别是不同的，例如SQL Server、Oracle默认Read Commited

REQUIRED：业务方法需要在一个事务中运行。如果方法运行时，已经处在一个事务中，那么加入到该事务，否则为自己创建一个新的事务。 NOT_SUPPORTED：声明方法不需要事务。如果方法没有关联到一个事务，容器不会为它开启事务。如果方法在一个事务中被调用，该事务会被挂起，在方法调用结束后，原先的事务便会恢复执行。 REQUIRESNEW：属性表明不管是否存在事务，业务方法总会为自己发起一个新的事务。如果方法已经运行在一个事务中，则原有事务会被挂起，新的事务会被创建，直到方法执行结束，新事务才算结束，原先的事务才会恢复执行。 MANDATORY：该属性指定业务方法只能在一个已经存在的事务中执行，业务方法不能发起自己的事务。如果业务方法在没有事务的环境下调用，容器就会抛出例外。 SUPPORTS：这一事务属性表明，如果业务方法在某个事务范围内被调用，则方法成为该事务的一部分。如果业务方法在事务范围外被调用，则方法在没有事务的环境下执行。 Never：指定业务方法绝对不能在事务范围内执行。如果业务方法在某个事务中执行，容器会抛出例外，只有业务方法没有关联到任何事务，才能正常执行。 NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按REQUIRED属性执行.它使用了一个单独的事务， 这个事务拥有多个可以回滚的保存点