事务的四大属性（ACID）

•  Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
•  Consistency（一致性）：在事务开始前、进行中、结束后，数据库的完整性没有被破坏。数据库的完整性（实体、参照、自定义）要求，包括唯一约束、外键约束、非空约束、有效值区间等自定义约束不会被破坏。
•  Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。简单来说就是，在事务执行的过程中，无论发生任何数据的改变都应该只存在于当前事务之中，对外界不存在任何影响（外界看不到未提交事务的数据变更）；只有在事务确定正确提交之后，才会显示该事务对数据的改变，其他事务才能获取到这些改变后的数据。
•  Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

其实事务主要是为了实现 C ，也就是一致性，具体是通过AID，即原子性、隔离性和持久性来达到一致性的目的。笼统的来说，undo支撑A-原子性、redo支撑D-持久性、锁支撑I-隔离性。

事务的隔离级别：

事务的隔离级别，本质上是数据库对共享锁的处理（加不加锁、锁定时间及锁定范围），分别对应不加锁、读完即释放、读完直至事务结束后释放、读取范围锁直至事务结束后释放。

不同隔离级别下的问题描述：

 上图为read-uncommited隔离级别，存在读到未提交数据的问题。

 上图为read-commited隔离级别，存在不可重复读的问题。

上图为repeatable-read隔离级别，存在幻读的问题。

多版本并发控制MVCC（Multi-Version Concurrency Control）

简单来说，在MVCC机制还没有出现之前，数据库中读写是互斥的，而通过MVCC机制使得读写不互斥。

因此MVCC使关系型数据库并发读写能力得到很大的提高，而大多数OLTP系统中的85%以上是读操作。

锁管理

共享锁（S）

排他锁（X）

更新锁

表级锁、页级锁

架构锁

范围锁

意向共享锁、意向排他锁

丢失修改（Lost to modify）

指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1修改A=A-1，事务2也修改A=A-1，最终结果A=19，事务1的修改被丢失。

乐观锁与悲观锁

解决丢失修改的方案一般有两种，即悲观锁与乐观锁，核心思想是假定并发操作产生冲突的概率（发生概率很大或不允许存在冲突，就选择悲观锁，否则可以选择乐观锁）。

悲观锁的实现方式：1、数据库层面的排他锁（select ....for update）或数据锁（字段状态标志）； 2、编程语言层面的synchronized或Redis等中间件；

乐观锁的实现方式：1、给数据增加version或时间戳等版本字段，修改时检查版本是否跟读取时一致；

分布式锁本质上是一种数据锁，属于悲观锁的范畴，应用于对数据一致性要求非常高的场景，不允许任何并发冲突。

"锁等待"和"死锁"的区别

1. "死锁"是锁等待形成回路，发生死锁马上会被innodb引擎检测出来，并且回滚其中的一个事务； 而"锁等待“需要其中一个事务等待超过innodb_lock_wait_timeout值才会回滚

2. ”锁等待“超时抛出的错误：Lock wait timeout exceeded; try restarting transaction；而”死锁“抛出的错误是：Deadlock found when trying to get lock; try restarting transaction

分布式事务：

在分布式系统中，当一个业务操作需要跨多个独立服务（或数据库）才能完成时，就会涉及分布式事务。它的核心目标是保证这些跨节点的操作要么全部成功，要么全部失败，最终实现数据的一致性。

分布式事务会部分遵循 ACID 规范：因为事务过程中，不是完全一致的，但事务会最终完成，最终达到一致，所以我们把分布式事务称为“最终一致性”

• 原子性：严格遵循
• 一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
• 隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
• 持久性：严格遵循