（一）数据库事务-事务的特性

     

       在移动互联网时代，有事没事给朋友发个红包很正常吧。假设今天是情人节，你为了讨女朋友欢心，打算给她发个520元的小红包。你激动的发完红包，放佛看到了女朋友满脸的喜悦和对你的爱慕。但是过了好久，你女朋友好久没有任何回复，你期盼的“么么达”没有出现。心急的你看了下自己的手机钱包，发现520元确实已经从账户扣除。这时你会不会担心，这520元从自己的账户上扣除了，但是没有到达女朋友的账户。

可能你的担心不止这些，在你给女朋友发红包的时候，老板觉得你这个月干得漂亮，给你发了个大红包，这时候若发女朋友的红包退回来，会不把老板发的红包金额给忽略掉。

你的这些担心是否多余呢？

一.概念

其实数据库事务可以给你答案。数据库事务是数据库执行的一个逻辑工作单元，是用户定义的一个数据库操作序列，这些操作要么全部做要么全不做，是一个不可分割的工作单位。

给女朋友发红包，简单的看可以包含两个操作：a.从你的账户上扣除520元。b.给女朋友的账户加520元.

二.目的

数据库事务的目的，恰恰是为了解决你的担心。

1.提供了可靠的执行单元以从灾难恢复中保持数据的一致性。在系统发生异常执行终止，许多操作未完成或者执行完成状态不清楚时，能够从失败中正确恢复数据，以保持数据库的一致性。

2.能够在并发的两个程序间提供隔离。如果没有提供隔离，最终程序的输出结果可能是错误的。

三.事务的特性(ACID)

事务提出了“All-Or-Nothing”的概念，每个数据库的执行单元，要么全部执行完毕，要么全部失败。

而且，每个事务之间应该是隔离的，最终执行结果应该保持数据之间的一致。最终成功的执行结果能够永久存储。

1.原子性（Atomic）
事务必须是原子工作单元，对于其数据修改，要么全部执行，要么全部不执行。比如在给女朋友发红包的过程中，从你账户上扣除520元的操作已经执行了，女朋友账户上增加520元的操作还没有执行，这时候系统突然出现故障停机。那么在系统重启恢复数据的时候，这次发红包的所有操作都必须回滚。从你账户扣除的520元必须回到你的账户上（所以你的担心有点多余）

2.一致性 （Consistence）
一致性保证了每次事务都从一个合法的状态到另一个合法的状态，所有写入数据库的数据都必须合法。所谓的合法是指程序级别定义的规则，包括各种约束、触发,级联以及它们的组合。一致性并不能保证所有可能的事务结果正确性，它仅仅保证不违反已定义的程序错误。

3.隔离性（isolation）
为了说明隔离性，我们假定两个事务在同一时间尝试修改相同的数据，其中的一个事务必须等另一个事务执行完之后才能执行。

比如发红包例子中，T1：你发520元红包给女朋友，T2：老板发10000元给你，包含四个操作

1.T1你的账户扣去520元

2. T1女朋友的账户加上520元

3.T2老板的账户扣去10000元

4.T2
你的账户加上10000元

如果这些操作是按以上顺序执行，隔离性当然没被破坏。如果事务交叉执行，实际的执行顺序是1,3,4,2。那么会发生什么了，如果T1你给女朋友转账失败了，T2已经给你的账户加了10000元，那么因为隔离性，T2的执行结果在T1回滚退出之前，都不会真实发生。只有当你发女朋友的红包退还到你的账户时，老板发你的钱才能真正到帐

4.持久性（durability)
事务一旦提交，在事务中对数据进行修改也就进行持久话存储类，不会因为系统故障导致提交后的数据丢失。

四.事务的操作模型

BEGINTRANSACTION

IF（OOERR)

ROLLBACKTRANSACTION;

ELSE

COMMITTRANSACTION
概念翻译：

数据库事务：Databasetransaction

原子性：atomic

一致性：consistent

隔离性：isolated

持久性：durable

提交：commit

未提交：uncommit

回滚：rollback