数据库事务：
数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作（也就是事物所包含的全部子集操作）都成功完成，否则不会永久更新面向数据的资源。
事物是为了保证数据库数据库的一致性而产生。
事务事务四大特征（ACID）：
原子性：事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。如果只执行一半，则之前对数据库所做的操作将不会执行。
一致性：事务在完成时，必须使所有的数据都保持一致状态。 比如两个账户之间进行转账，修改前后两个账户余额总数应该一致。
隔离性：在并发事务中，当前事务中对数据所做的操作，必须与其他并发中的事务操作隔离，当前事务查看数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，不能有两种状态。
持久性：事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。
要想真正的做到操作之间完全没有任何干扰是很难的，所以有了事务隔离级别，来规范事务的隔离性：
1.READ_UNCOMMITTED
2.READ_COMMITTED
3.REPEATABLE_READ
4.SERIALIZABLE
级别越高，隔离性越强，但是并发性能越弱，所以很多厂商都会降低事务的隔离级别来换取并发量吞吐量。
原因：对事务进行隔离性处理需要处理同步问题，例如上锁，锁加的多了并发级别也就低了。
原子性是基础，隔离性是手段，持久性是目的，最重要的就是一致性
隔离性所产生的数据问题：
1.脏读
2.不可重复读
3.幻读
4.第一类update（由于撤销更改）
5.第二类update（由于提交更改）
Capture.PNG
( 脏读绝对不允许存在，但是2.3通常在要求非常高的系统中才会做处理 )
可重复读 的弊端
可重复读不是真的要读两次，而是指一个事务在使用这个值的时候，这个值被其他事务修改了，那么以这个值为基础的计算都是错的，如果计算后再写回数据库就会造成不一致（整个数据库的不一致）
所以银行的统计是不允许可重复读的，（统计事务与修改数据事务必须隔离开）
不可重复读与幻读的区别
表面上看这两种数据问题都是因为在并发事务A内进行了两次读操作，而B并发操作数据提交后，导致A并发两次读操作读到的数据不一致。
可以从解决方来理解：（这里的解决方案只是最简单不考虑性能）
1.解决不可重复读，可以在A事务中对数据库数据的update进行上锁，导致B事务无法中途修改数据，解决了A事务重复读取不一致的问题。但是如果此时B事务进行的是insert或delete操作（并没有上锁），B事务第二次查询的时候多了一条数据，可谓产生了幻觉，所以这种解决方案并不能解决幻读。
2.为了解决幻读问题，可以将insert操作也上锁，即为 “悲观锁”，在整个数据处理过程中，将数据处 于锁定状态。另一种解决方案为乐观锁。一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如 果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
事务的作用与目的
保证数据的一致性与完整性
网友评论