事务的四大特性ACID

定义：所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。

我们以前在数据库原理中学到事务具有ACID特性。

1.原子性 Atomicity

要么做，要么不做。这个例子挺多的，就像二进制0/1 开关一样，要么开，要么关，不存在什么半开。还有类似boolean类型数据，就只有true ，false 。就像誓死如归的军人，要么战死，要么凯旋，绝对不会投降。

2.一致性 Consistency

要求A+B = 10 ，A B 两个变量必须一致，A=1 ，B一定要等于9，A=2,B一定要等于8.比如csdn博客，你关注了我 ， 那么你就是我的粉丝，数据库两头都要存储。还有银行转账这个经典的例子。

 一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性：

     强一致性：读操作可以立即读到提交的更新操作。

     弱一致性：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。

     最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。

     其他一致性变体还有：

     单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。

     会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。 

　　保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。

　　保证数据库的一致性是数据库管理 系统的一项功能.比如有两个表(员工\职位),员工表中有员工代码、姓名、职位代码等属性，职位表中有职位代码、职位名称、职位等级等属性。你在其中员工表中进行了插入操作,你插入了一个新员工的信息，而这个新员工的职位是公司新创建的一个职位。如果没有一致性的保证，就会出现有这么一个员工，但是不知道他到底担当什么职责！这个只是它的一个小小方面。 

 

　　读一致性也是数据库一致性的一个重要方面,在实际中,我们会遇到这种情况:我们对一个表中的某些数据进行了更新操作,,但是还没有进行提交,这时另外一个用户读取表中数据.这个时候就出现了读一致性的问题:到底是读什么时候的数据呢?是更新前的还是更新后的?在DBMS中设有临时表,它用来保存修改前的值,在没有进行提交前读取数据,会读取临时表中的数据,这样一来就保证了数据是一致的.(当前用户看到的是更新后的值)   www.2cto.com  

 

　　但是还有一种情况:用户user1对表进行了更新操作,用户user2在user1还没有进行提交前读表中数据,而且是大批量的读取(打个比方:耗时3分钟)而在这3分钟内user1进行了提交操作,那又会产生什么影响呢?这个时候怎么保证读写一致性呢?这个时候DBMS就要保证有足够大的临时表来存放修改前的数值,,以保证user2读取的数据是修改前的一致数据.然后下次再读取时候就是更新后的数据了

3.隔离型 Isolation

就是说并发事务之间不会互相影响，与串行执行的效果一样。

总的说，数据库事物无非就两种：读取事物（select）、修改事物（update,insert）。在没有事物隔离控制的时候，多个事物在同一时刻对同一（数据的操作可能就会影响到最终期望的结果，通常有四种情况

（1） 两个更新事物同时修改一条数据时，很显然这种情况是最严重的了，程序中无论如何也不能出现这种情况，因为它会造成更新的丢失！通俗的讲，我更新时，你丫也更新这不就出问题了吗，艹，不行！

（2） 一个更新事物更新一条数据时，另一个数据读取了还没提交的更新，这种情况下会出现读取到脏数据。通俗的讲就是，丫的，让你在我更新的时候读取，老子还没提交你丫就读，活该吧，老子提交前又修改了数据，你丫读到脏数据了，活该！

（3） 一个读取事物读取一条数据时另一个更新事物修改了这条数据，这时就会出现不可重现的读取。通俗的讲，麻痹的，老子读数据呢，谁让你丫的修改了，艹，害老子读了不一样的数据。

（4）一个读取事物读取时，另一个插入事物（注意此处时插入，三中时更新同一条数椐，自己体会）插入了一条新数据，这样就可能多读出一条数据，出现幻读。通俗的讲，哥们我读取数据的时侯你插入新数据了是的？怪不得多读了一条呢还以为中奖了呢！FUCK！

以上四种情况描述完毕，相信大家也发现规律了，前三种是对同一条数据的并发操作，对程序的结果可能产生致命影响，尤其是金融等实时性，准确性要求极高的系统，绝不容许这三中情况的出现，相比第四种情况不会影响数据的真实性，在很多情况下是允许的，如社交论坛等实时性要求不高的系统！

综上四个情况，我们可以大致这样简单的理解（最初说的两种事物的自由组合2*2=4）：

A） 修改时允许修改（丢失更新）

B） 修改时允许读取（脏读）

C) 读取时允许修改（不可重复读）

D) 读取时允许插入（幻读）

从上到下问题越来越不严重，但所需的性能开销却越大。因为不同的系统允许不同级别的情况，所以就出现了事务隔离这么一个东东，来允许我们设定数据库的并发行为。

其中

1）读取未提交， 这个级别就是一个事物更新的时候不允许更新，但允许读取，说以不会出现丢失更新，单会出现脏读。隔离级别最低。

2）读取已提交数据，就是一个事物更新的时候不允许读取，必须等到更新事物提交后才能读取，不会出现脏读，但可能出现不可重复度。隔离级别次低。

以上两种级别是针对更新事物的限制，在读取事物进行时，是不会有任何限制的。所以会出现不可重复读（读取时，有更新），和幻读（读取时，插入）。

3）可重现的读取，就是一个事物读取时，不允许更新，但允许插入。不会出现不可重复读，但会出现幻读。

4）序列化(大招），你麻，只要有事物进行，其他事物必须他妈乖乖等着老子执行完。霸气侧漏，所以不会出现任何并发问题。

以上两个事物会限制读取事物的，所以隔离级别较高，但性能开销不容小觑。

4.持久性 Durability

一旦事务提交成功，数据修改是永存的。