事务的4大特性（ACID）

 

事务的4大特性（ACID）

如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：

原子性，一致性，隔离性，持久性

• 原子性(Atomicity)：事务是数据库的逻辑工作单位，它对数据库的修改要么全部执行，要么全部不执行。 

原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，所以事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。为了实现原子性，需要通过日志：将所有对数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已经执行成功的操作撤销，从而达到“全部操作失败”的目的。

• 一致性(Consistemcy)：事务前后，数据库的状态都满足所有的完整性约束。 

一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态，不允许出现中间状态。举例：

      拿转账来说，假设用户A有1000块钱，用户B有2000块钱，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是3000，这就是事务的一致性。事务不一致的情况：

（1）用户A给用户B转500块钱，此时用户A账户减去500元，剩下500元，但是此时突然系统崩溃了，用户B没来得及加500，此时的数据库就出现了不一致的状态。

（2）事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上500。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了500元。那么最后的结果应该是A增加了1000元。但事实上，事务1最终完成后，帐号A只增加了500元，因为事务2的修改结果被事务1覆盖掉了。这使得三个账户转账后，数据的不一致。其实，原子性，隔离性，以及持久性都是为了保证数据库数据的一致性。

• 隔离性(Isolation)： 并发执行的N个事务是隔离的，一个不影响一个，一个事务在没有commit之前，被修改的数据不可能被其他事务看到（通过设置数据库的隔离级别）。 

隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。

　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。

• 持久性(Durability)： 持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。持久性主要在于DBMS的恢复性能。

持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

　　例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

事务的隔离级别从低到高

1. 未提交读（Read Uncommitted）：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
2. 提交读（Read Committed）：只有在事务提交后，其更新结果才会被其他事务看见。解决脏读问题。
3. 可重复读（Repeated Read）：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
4. 串行读（Serialization）：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。通常，在工程实践中，为了性能的考虑会对隔离性进行折中。