事务的特性

Posted 2023-04-18

参考技术A 在工作中，经常会接触到事务这个概念。涉及到事务，大家首先想到的就是事务的四个特性：ACID。
1.原子性（Atomicity）
1.1什么是原子性
一般来说，原子是指不能分解成小部分的东西。这个词在计算的不同分支中意味着相似但又微妙不同的东西。例如，在多线程编程中，如果一个线程执行一个原子操作，这意味着另一个线程无法看到该操作的一半结果。系统只能处于操作之前或操作之后的状态，而不是介于两者之间的状态。 ACID原子性的定义特征是：能够在错误时中止事务，丢弃该事务进行的所有写入变更的能力。
1.2 如何实现原子性
WAL（预写日志） 是用于保证事务的原子性和持久性。简单来讲，事务更新数据之前，先写日志，然后在更新数据。当系统崩溃时，如果事务还没写WAL，那整个数据依然一致。如果事务只写了WAL，未更新具体的数据页后崩溃，那恢复流程可以根据WAL日志，重做相关操作，保证数据一致性。
2.一致性（Consistency）
ACID一致性的概念是，对数据的一组特定陈述必须始终成立。即不变量（invariants）。例如，在会计系统中，所有账户整体上必须借贷相抵。如果一个事务开始于一个满足这些不变量的有效数据库，且在事务处理期间的任何写入操作都保持这种有效性，那么可以确定，不变量总是满足的。 原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。
3.隔离性（Isolation）
3.1什么是隔离性
大多数数据库都会同时被多个客户端访问。如果它们各自读写数据库的不同部分，这是没有问题的，但是如果它们访问相同的数据库记录，则可能会遇到并发问题（竞争条件（race conditions））。 ACID意义上的隔离性意味着，同时执行的事务是相互隔离的：它们不能相互冒犯。
如果两个事务不触及相同的数据，它们可以安全地并行（parallel） 运行，因为两者都不依赖于另一个。当一个事务读取由另一个事务同时修改的数据时，或者当两个事务试图同时修改相同的数据时，并发问题（竞争条件）才会出现。出于这个原因，数据库一直试图通过提供事务隔离（transaction isolation） 来隐藏应用程序开发者的并发问题。
serializable级别的隔离，保证事务的效果与连续运行（即一次一个，没有任何并发）是一样的，可以保证事务地安全执行。但是在serializable隔离级别，事务并发度很低，整个数据库的性能肯定不高。这时候，数据库开发人员有提出了四种不同的隔离级别，来平衡事务并发度与隔离性，这四个隔离级别分别是：
读未提交（Read Uncommitted）：可以读取未提交的记录。
读已提交（Read Committed）：事务中只能看到已提交的修改。
可重复读（Repeatable Read）：解决了不可重复读问题（mysql 默认隔离级别）
序列化（Serializable）：最高隔离级别。
RU,RC和RR由于降低了隔离要求，自然在读取数据时，会产生各种异常（上帝为你打开一扇门的同时，肯定也为你关上一扇窗）：
RU会读取其他事务未提交的数据，这就产生了脏读，脏读取意味着另一个事务可能会只看到一部分更新，或者看到的数据已经被回滚了。
RC级别的隔离，会产生不可重复读的问题。所谓不可重复读是指在一个事务内根据同一个条件对行记录进行多次查询，但是搜出来的结果却不一致。发生不可重复读的原因是在多次搜索期间查询条件覆盖的数据被其他事务修改了。
RR级别的隔离，会产生幻读问题。幻读，并不是说两次读取获取的结果集不同，幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些：select 某记录是否存在，不存在，准备插入此记录，但执行 insert 时发现此记录已存在，无法插入，此时就发生了幻读。
3.2 如何支持隔离性
一般数据库不会考虑工作在RU隔离级别，因为读脏数据会引起太多的问题。数据库一般工作在RC或RR隔离级别，快照隔离级别就可以支持RC或RR隔离级别，所以数据库一般会实现快照隔离级别。
快照隔离的实现通常使用写锁来防止脏写，这意味着进行写入的事务会阻止另一个事务修改同一个对象。但是读取不需要任何锁定。从性能的角度来看，快照隔离的一个关键原则是：读不阻塞写，写不阻塞读。这允许数据库在处理一致性快照上的长时间查询时，可以正常地同时处理写入操作。且两者间没有任何锁定争用。
为了实现快照隔离，数据库必须保留一个对象的几个不同的提交版本，因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象，所以这种技术被称为多版本并发控制（MVCC, multi-version concurrentcy control）。
最高的隔离级别：Serializable，一般是通过2PL来实现， 一阶段申请，一阶段释放。读写都要加锁。
4.持久性(Durability)
数据库系统的目的是，提供一个安全的地方存储数据，而不用担心丢失。持久性 是一个承诺，即一旦事务成功完成，即使发生硬件故障或数据库崩溃，写入的任何数据也不会丢失。

什么是事务事务特性事务隔离级别spring事务传播特性

1.什么是事务：

事务是程序中一系列严密的操作，所有操作执行必须成功完成，否则在每个操作所做的更改将会被撤销，这也是事务的原子性（要么成功，要么失败）。

2.事务特性：

事务特性分为四个：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持续性（Durability）简称ACID。

1. 原子性（Atomicity）:事务是数据库逻辑工作单元，事务中包含的操作要么都执行成功，要么都执行失败。
2. 一致性（Consistency）：事务执行的结果必须是使数据库数据从一个一致性状态变到另外一种一致性状态。当事务执行成功后就说数据库处于一致性状态。如果在执行过程中发生错误，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这是数据库就处于不一致状态。
3. 隔离性（Isolation）：一个事务的执行过程中不能影响到其他事务的执行，即一个事务内部的操作及使用的数据对其他事务是隔离的，并发执行各个事务之间无不干扰。
4. 持续性（Durability）：即一个事务执一旦提交，它对数据库数据的改变是永久性的。之后的其它操作不应该对其执行结果有任何影响。

3.事务的隔离级别：

事务的隔离级别也分为四种，由低到高依次分别为：read uncommited（读未提交）、read commited（读提交）、read repeatable（读重复）、serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。

1. read uncommited：是最低的事务隔离级别，它允许另外一个事务可以看到这个事务未提交的数据。
2. read commited：保证一个事物提交后才能被另外一个事务读取。另外一个事务不能读取该事物未提交的数据。
3. repeatable read：这种事务隔离级别可以防止脏读，不可重复读。但是可能会出现幻象读。它除了保证一个事务不能被另外一个事务读取未提交的数据之外还避免了以下情况产生（不可重复读）。
4. serializable：这是花费最高代价但最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读之外，还避免了幻象读。
5. 脏读、不可重复读、幻象读概念说明：

• • 脏读：指当一个事务正字访问数据，并且对数据进行了修改，而这种数据还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据还没有提交那么另外一个事务读取到的这个数据我们称之为脏数据。依据脏数据所做的操作肯能是不正确的。
  • 不可重复读：指在一个事务内，多次读同一数据。在这个事务还没有执行结束，另外一个事务也访问该同一数据，那么在第一个事务中的两次读取数据之间，由于第二个事务的修改第一个事务两次读到的数据可能是不一样的，这样就发生了在一个事物内两次连续读到的数据是不一样的，这种情况被称为是不可重复读。
  • 幻象读：一个事务先后读取一个范围的记录，但两次读取的纪录数不同，我们称之为幻象读（两次执行同一条 select 语句会出现不同的结果，第二次读会增加一数据行，并没有说这两次执行是在同一个事务中）

spring事务传播特性：

事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。spring支持7种事务传播行为：

• • propagation_requierd：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。
  • propagation_supports：支持当前事务，如果没有当前事务，就以非事务方法执行。
  • propagation_mandatory：使用当前事务，如果没有当前事务，就抛出异常。
  • propagation_required_new：新建事务，如果当前存在事务，把当前事务挂起。
  • propagation_not_supported：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
  • propagation_never：以非事务方式执行操作，如果当前事务存在则抛出异常。
  • propagation_nested：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与propagation_required类似的操作

Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。假设 ServiveX#methodX() 都工作在事务环境下（即都被 Spring 事务增强了），假设程序中存在如下的调用链：Service1#method1()->Service2#method2()->Service3#method3()，那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。