数据库事务

摘自：https://www.cnblogs.com/protected/p/6526857.html 关于数据库的各种锁的总结： 1.共享锁（又称读锁）、排它锁（又称写锁）： InnoDB引擎的锁机制： InnoDB支持事务，支持行锁和表锁用的比较多，Myisam不支持事务，只支持表锁。 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。 排他锁（X)：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。 意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。 意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。 说明： 1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。 2）对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。 共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 排他锁（X)：SELECT * FROM table_name

分布式事务Saga (一) TCC vs Saga 分布式事务Saga（二）事务管理者SagaTransactionalAspect 分布式事务Saga（三）事务参与方管理SagaParticipantAspect 分布式事务Saga（四）事务恢复SagaRecoveryManager 文章目录 TCC流程 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 saga 正常流程图 saga 异常流程图 结论 项目地址： https://github.com/yangxb2010000/saga 该项目的实现本质上说不是一个严格意义上的Saga实现，更像是一个简化版的TCC事务 先对比一下Saga与TCC的区别 TCC流程 Try 预留资源 （如：库存服务的预占库存，支付服务的冻结部分账户余额） Confirm 如果所有的事务参与者try 操作都执行成功了，就会调用所有事务参与者的confirm操作，确认资源。（如：库存服务的减库存，支付服务的扣减账户余额） Cancel 如果有事务参与者在try阶段执行失败，就调用所有已执行try阶段成功的参与方的cancel方法，释放try阶段占用的资源（如：库存服务的释放预占库存，支付服务的释放冻结的账户余额） ####正常逻辑时序图 支付服务在调用try阶段失败的事务回滚 本项目Saga流程 confirm 直接执行资源操作，（如

1 、 @Entity(name="EntityName") 必须 ,name 为可选 , 对应数据库中一的个表 2 、 @Table(name="",catalog="",schema="") 可选 , 通常和 @Entity 配合使用 , 只能标注在实体的 class 定义处 , 表示实体对应的数据库表的信息 name: 可选 , 表示表的名称 . 默认地 , 表名和实体名称一致 , 只有在不一致的情况下才需要指定表名 catalog: 可选 , 表示 Catalog 名称 , 默认为 Catalog(""). schema: 可选 , 表示 Schema 名称 , 默认为 Schema(""). 3 、 @id 必须 @id 定义了映射到数据库表的主键的属性 , 一个实体只能有一个属性被映射为主键 . 置于 getXxxx() 前 . 4 、 @GeneratedValue(strategy=GenerationType,generator="") 可选 strategy: 表示主键生成策略 , 有 AUTO,INDENTITY,SEQUENCE 和 TABLE 4 种 , 分别表示让 ORM 框架自动选择, 根据数据库的 Identity 字段生成 , 根据数据库表的 Sequence 字段生成 , 以有根据一个额外的表生成主键 , 默认为AUTO generator:

Mysql锁技术详解 本文只讨论InoDB存储引擎下的锁。 前言 在分布式并发的场景下，对于共享资源的操作是非原子性的，这会造成操作和预期的结果并不一致。 原子性操作 ：指在一次CPU的调度时间类完成的一系列操作，顺序不可打乱，也不可只执行一部分。 任何可能能被CPU打断的操作都不是原子操作，所以真正的原子操作需要硬件支持，但是硬件大多数只支持系统的核心方法的原子操作，所以如果想要在自己开发的程序里做原子操作，需要引入锁。在线程A操作共享资源时需要拿到锁，这样即便线程A的操作中途CPU切换到了线程B，线程B想要读取共享资源时缺拿不到锁，所以线程B无法操作共享资源，这样就模拟出了原子操作，保证了线程A的逻辑是完整正确的。 MySQL的事务具有原子性，所以MySQL肯定实现了许多锁来保证原子操作。以InoDB为例，来看看MySQL实现了哪些锁，这些锁又分别有什么作用。 根据锁的范围来分类，大致分为了三类锁： 全局锁 表锁 行锁 全局锁 顾名思义，全局锁就是对整个数据库实例都加上锁，命令行是 Flush tables with read lock，一旦数据库加上此锁，除了当前操作线程之外，其他的线程对数据库的增删改操作都会被阻塞，包括建表，修改表结构事务更新等操作。 全局锁一般用于数据备份，为了保证备份的一致性，加上全局锁确保备份时间类数据库里的数据不会有更新。

1. 隔离级别 (1) 读不提交 (Read Uncommited ， RU) 这种隔离级别下，事务间完全不隔离，会产生脏读，可以读取未提交的记录，实际情况下不会使用。 (2) 读提交 (Read commited ， RC) 仅能读取到已提交的记录，这种隔离级别下，会存在幻读现象，所谓幻读是指在同一个事务中，多次执行同一个查询，返回的记录不完全相同的现象。幻读产生的根本原因是，在 RC 隔离级别下，每条语句都会读取已提交事务的更新，若两次查询之间有其他事务提交，则会导致两次查询结果不一致。虽然如此，读提交隔离级别在生产环境中使用很广泛。 (3) 可重复读 (Repeatable Read, RR) 可重复读隔离级别解决了不可重复读的问题，但依然没有解决幻读的问题。那么不可重复读与幻读有什么区别呢？不可重复读重点在修改，即读取过的数据，两次读的值不一样；而幻读则侧重于记录数目变化【插入和删除】。一般教科书上告诉我们只有到串行化隔离级别才解决幻读问题，但mysql的innodb比较特殊，RR即解决了幻读问题，主要通过GAP锁实现。另外， 不是所有的数据库都实现了该隔离级别，后面会简单介绍下 mysql 是如何实现可重复读隔离级别的。 (4) 串行化 (Serializable) 在串行化隔离模式下，消除了脏读，幻象，但事务并发度急剧下降，事务的隔离级别与事务的并发度成反比

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 掌握了JDBC最基本的与数据库交互后，接下来，我们要修炼进阶篇了，此篇涉及大量的专业名词，需要有一定天赋的修行者修炼，不过，我相信，能够轻松通过第一篇的你，绝对是那个骨骼精奇，天资聪慧的修行者~那么，我们进入此次的修行把---JDBC的事务管理 事务：在一个业务场景中，保持一系列操作的整体性，我们称作事务~简单来讲，在一系列的操作中，要么，所有操作都生效，要么所有操作都不生效，不存在某些操作生效，某些操作不生效的情况。举个例子~业务场景：小鱼儿转10定金子给花无缺；涉及的操作：1.钱从小鱼儿的兜里转出~2.钱转入到花无缺的兜中~，两个操作缺一不可，如果操作1在途中受阻，那么钱就会回到小鱼儿的兜中，只有这样，才能保证我业务操作的完整性。 事务的特性： 1、原子性（atomicity）：组成事务的语句形成了一个逻辑单元，不能只执行一部分； 2、一致性（consistency）：在事务处理执行前后，数据库与理论值是一致的（数据库完整性约束）； 3、隔离性（isolcation）：一个事务处理和另一个事务处理相互间互不影响； 4、持续性（durability）：事务处理的效果能够被永久保存下来。 隔离级别： 1、多线程并发执行可能会产生以下三个问题： 　　脏读（dirtyreads）

事务的特性 原子性： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用； 一致性： 执行事务前后，数据保持一致； 隔离性： 并发访问数据库时，一个用户的事物不被其他事物所干扰，各并发事务之间数据库是独立的； 持久性: 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。 Spring事务管理接口介绍 PlatformTransactionManager： （平台）事务管理器 TransactionDefinition： 事务定义信息(事务隔离级别、传播行为、超时、只读、回滚规则) TransactionStatus： 事务运行状态 所谓事务管理，其实就是“按照给定的事务规则来执行提交或者回滚操作”。 Spring并不直接管理事务，而是提供了多种事务管理器 ，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。 Spring事务管理器的接口是： org.springframework.transaction.PlatformTransactionManager ，通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。 PlatformTransactionManager接口代码如下

四种隔离级 1,read uncommitted(读取未提交内容) 在read uncommitted隔离级，所有事务都可以“看到”未提交事务的执行结果。在这种级别上，可能会产生很多问题，除非用户真的知道自己在做什么，并且很多的理由选择这样做。本隔离级别很少用于实际应用，因为它的性能也不必其他级别好多少，而别地级别还有其他更多的优点。读取未提交数据，也被称之为脏读(dirty read)。 2,read committed(读取提交内容) 大多数数据库系统的默认隔离级别为read committed（但不是mysql默认的）。它满足了隔离级别早先简单定义：一个事务在开始时，只能”看见“已经提交事务所做得改变，一个事务从开始到提交前，所做得任何数据改变都是不可见的，除非已经提交。这种隔离级别也支持 所谓的”不可重复读(nonrepeatable)“,意味着用户运行同一语句两次，看到的结果是不同的。 3,repeatable read(可重读) repeatable read隔离级解决了read uncommitted隔离级导致的问题。它却确保同一事务的多个实例在并发读取数据时，会”看到同样地“数据行。不过理论上，这会导致另外一个棘手的问题，幻读(phantom read)。简单来说，幻读指当用户读取某一个范围的数据行时，另外一个事务又在该范围内插入插入了心行

前言： 我一直想不到一个好的标题应该怎么写。我想MySQL的一些重要的内容。我在两次面试中都遇到过的，但直接用MySQL标题好像又不太贴切。干脆就是所写的内容吧。 MySQL事务： transaction Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. Database transactions, as implemented by InnoDB , have properties that are collectively known by the acronym ACID, for atomicity, consistency, isolation, and durability. See Also ACID , commit , isolation level , lock , rollback

原文: MySQL 架构 MySQL架构和结构分析 官方架构图： MySQL DB 各模块架构图如下： MySQL安装方式 MySQL初始化 简介：什么是事务； 事务： ACID ： 事务确保了银行不会弄丢你的钱，而这种特性在应用逻辑设计中是很难实现的，甚至不可实现。一个ACID兼容的数据库服务器，要为事务处理大量的复杂工作确保ACID特性的实现，而这也许是用户未能察觉到的。 事务： ACID ： A ：原子性(Atomicity) ： 一个事务必须被视为一个单独的内部”不可分“的工作单元，以确保整个事务要么全部执行，要么全部回滚。当一个事务具有原子性时,该事务绝对不会被部分执行,要么完全执行，要么根本就不执行。 C：一致性 (consistency)： 数据库总是从一种一致性状态转换到另一种一致性状态。只要是最终事务没有被提交，任何事务处理过程中所做的数据改变，也不会影响到数据库的内容。 I：隔离性 (leolation) ： 某个事务的结 果只有在完成之后才对其它事务可见 D：持久性(durability) ： 一旦一 个事务提交，事务所做的数据改变是永久的。这意味着数据改变已被记录，即使系统崩溃，数据也不会因此丢失，持久性是个有点模糊的概念，因为实际上持久性也分为很多级别。 隔离： 隔离级别 read uncommitted ： 读 未提交内容：在read