标签：
引自：http://blog.csdn.net/turkeyzhou/article/details/7636165
1.1 我们为什么需要事务
数据库事务(Database Transaction) ，是指作为单个逻辑工作单元执行的一系列操作。事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关 操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、 一致性、隔离性和持久性)属性。
上面的解释和描述来自百度百科（http://baike.baidu.com/view/1298364.htm），我们为什么需要事务，通俗点说，就是需要“一组操作或者行为，要么全成功，要么全失败，一荣俱荣，一辱俱辱”。
1.2 事务ACID属性
事务的特性可以定义为四种属性：ACID（atomicity，consistency，isolation，durability）。
l atomicity：原子性，在一个事务中的所有操作，相当于一个原子操作，要么全部成功，要么全部失败。
l consistency：一致性，就是在事务执行前后，对于事务本身的用意而言，数据库中的数据是保持一致的，数据库的一致性是建立在原子性的基础之上的，更多的由编码的程序员保证，最经典的案例是A，B帐号之间的转账。
在整个过程中，对于一致性的定义是AB的账户总额保持事务前后一致，而次数是通过事务的原子性以及事务定义的编码共同来实现的（如果你本意是转账，A减去50而B加上100则不符合一致性本意）。
另一方面则表示，一致性状态表示只有合法的数据才能被写入数据库，如果事务执行的某些操作，违反了数据的一致性规则，则 事务会rollback到之前数据一致的状态，另一方面，如果事务执行成功，则会将数据状态从事务执行前的符合数据一致性规则的一种状态，变迁到事务执行 后的另一种数据符合一致性规则的状态。（Definition: Consistency states that only valid data will be written to thedatabase. If, for some reason, a transaction is executed that violates thedatabase’s consistency rules, the entire transaction will be rolled back andthe database will be restored to a state consistent with those rules. On theother hand, if a transaction successfully executes, it will take the databasefrom one state that is consistent with the rules to another state that is alsoconsistent with the rules.）
l isolation:隔离性，事务的隔离性是指事务和事务之间的数据可见性，这也是本文需要详细介绍的地方。数据库定义了各种隔离级别，以在并发性和数据完整性中权衡。
l durability：持久性,事务完成以后，所有的数据都将持久到数据库中，不会因为其他原因而丢失。
事务的隔离性是指当多个事务并发同时执行的时候，数据的可见性不同而导致的一些问题，主要问题包括如下四种：
l 更新丢失（同时更新）；
当两个事务同时对一条数据进行更新的时候，因为执行顺序交叉，在没有协同的情况，可能导致某一个事务的更新被覆盖，我们称之为更新丢失（这在银行转账中是十分危险和不可接受的）。
l 脏读；
顾名思义，脏读，未提交读，均是指事务在同事读写的过程中间，一个事务读取到另一个事务没有commit的更新，此时，这个更新是否会被正式提交，或者发生异常回滚是不可预料的，所以可以认定此时所读取到的数据为脏数据。
l 不可重复读
不可重复读取主要是因为在一次事务中多次读取某条记录，但因为其他事务的介入，而导致多次读取的值不一致。
l 幻读；
幻读主要在事务A中读取记录数为N条，而事务B插入一条，则事务A再次读取时则变成了N+1条。
3.1 锁的类型
如同线程一样，数据库也用锁来保证事务之间的协同工作，在数据库中，锁分为共享锁和排他锁，顾名思义，多个共享锁可以共存，而排它锁则是独占锁，共享锁也称之为读锁，而排它锁也称之为独占锁，写锁。
l 排他锁 被加锁的对象只能被持有锁的事务读取和修改，其他事务无法在该对象上加其他锁，也不能读取和修改该对象
l 共享锁 被加锁的对象可以被持锁事务读取，但是不能被修改，其他事务也可以在上面再加共享锁。
特别的，对共享锁： 如果两个事务对同一个资源上了共享锁，事务A 想更新该数据，那么它必须等待 事务B 释放其共享锁。
3.2 锁粒度
锁的范围和粒度可以分为表锁和行锁，其中表锁为数据库实现，而行锁则由存储引擎实现（如innodb引擎）。
3.3 封锁协议（Locking Protocol）
在运用锁来进行事务之间的协议时，还必须基于一定的规则，如何时加锁，何时释放锁，加锁的粒度以及等等。这些称之为封锁协议，不同的封锁协议定义了不同的隔离级别。不同的隔离级别则解决了之前事务协作锁带来的问题，以便服务在吞吐量和并发性以及事务完整性之间做出权衡。
针对事务协作锁带来的四大问题，于是根据不同的封锁协议，制定了事务间的隔离级别。其实本质上均是通过锁来干涉事务之间的执行顺序。
4.1 事务协作问题原因极其分析
l 丢失更新
原因：读锁可以共享，而记录常驻内存。
解决方式：读锁升级为独占锁，或者重复读取，cas更新。
l 脏读
执行场景（顺序）：事务A在事务B更新数据和回滚过程中间读取记录。
解决方式：当事务B更新数据的时候禁止其他事务对记录进行读取。
加锁方式：事务B将写锁（独占锁）保持到事务结束。
l 不可重复读
执行场景（顺序）：事务A第一次读取数据在事务B更新数据并提交之前，第二次读取数据在事务B更新记录并提交之后，导致同一次事务中多次读取同一记录不同。
解决方式：事务A在读取数据和提交事务之间不允许其他事务对数据进行修改。
加锁方式：事务A持有共享锁直至事务结束。
l 幻读
解决方式：数据库将行锁升级为表锁；
4.2 隔离级别及对应封锁规则
l read uncommitted(一级封锁规则)
表示可以接受读取未提交的数据（脏读）。封锁规则为：当事务修改记录时，为记录添加共享锁直至事务结束，在次过程中，其他事务可以读取和更新数据。因此此种隔离级别会带来丢失更新，脏读，重复读，幻读各种问题。
l read commited（二次封锁规则）
表示允许读取提交后的数据，意思是允许（不可重复读）现象，但拒绝脏读。
封锁规则为对应的脏读解决方案，事务将写锁（独占锁）保持到事务结束，而读取数据的时候当读取操作完毕则立即释放读锁。
执行顺序会变成：
l repeatable read（三级封锁协议）
表示可以重复读（意思为不允许不可重复读，真纠结）。封锁规则为，保持共享锁到事务结束。
但因为是行锁，无法避免幻读，另外因为事务读锁可以并存，那是否repeatable read在应对丢失更新的情况方面表现如何呢？
你会发现，因为共享锁和排他锁的释放周期均被放大，导致了资源的死锁，数据库如何解决这种死锁状况呢？如SQL Server在处理这种情况时则是引入了Update锁，当读取数据的时候为记录上获取Update锁，哪个事务先修改，则将锁升级为独占锁从而对该数据 进行修改。而mysql innodb则主要是通过两方面来处理死锁问题：
n 死锁检测；当发现死锁时，将一个事务回退（回滚拥有最少排他行级锁的事务，一种对最易回滚事务的大致估算），令一个事务获得锁完成事务，但是innodb也无法检测所有死锁的问题。
n 死锁超时；可以通过设置innodb_lock_wait_timeout来设置获取锁而等待的超时时间。
l Serialization(四级封锁)
直接对 事务中 所 读取 或者 更改的数据所在的表加表锁，也就是说，其他事务不能 读写 该表中的任何数据。这样所有的 脏读，不可重复读，幻读 ，都得以避免。
在mysql中，可以通过如下命令查询当前事务隔离级别：
SELECT@@global.tx_isolation; //全局
SELECT@@tx_isolation;//当前会话
设置会话级别分别为：
setglobal transaction isolation level read committed;
setsession transaction isolation level read committed;
标签：
原文地址：http://www.cnblogs.com/nearpengju123/p/4914978.html
