Open XXHolic opened 5 years ago
最近看一些文章的时候，看到事务的概念，只记得在很早的时候接触过，想不起来有什么用，查询了资料后发现还是挺有用的。
事务处理（Transaction processing）是计算机科学中的信息处理，它被分成单个不可分割的操作，称为事务（transaction）。每个事务作为一个完整的单元必须成功或者失败，绝不可能部分完成。事务处理通过确保系统上相互依赖的操作，全部成功完成或者全部成功取消，在已知的一致状态上维持系统的完整性。
举个例子，一个典型的银行交易：将 100 从客户的储蓄账户转移到客户的支票账户。这个交易涉及至少 2 个独立的操作：借记储蓄帐户 100，记入支票账户 100。如果一个操作成功，另外一个操作失败，银行的账簿最后会不平衡。这里必须要有一个方式去保证所有操作都成功或都失败，这样在银行的整个数据库中才不会前后矛盾。
在事务中链接了多个操作时，确保所有的操作没有错误的完成，或者都失败。如果其中的一些操作完成但在尝试其它操作时发生了错误，则事务处理系统会“回滚（rolls back）” 事务的所有操作（包括已经成功的操作），从而消除事务的所有痕迹，并将系统恢复到处理事务开始之前所处的一致的已知状态。如果一个事务的所有操作都成功的完成，这个事务会被系统提交（committed），所有对数据库的更改将会是永久性的，一旦事务完成不能被回滚。
通常，事务是同时发布的，如果它们重叠，可能会产生冲突。例如一个客户的储蓄账户上有 150，尝试转账给另外一个人 100，同时转移 100 到支票账户，那么只有其中的一个可以成功。然而，强制事务按照顺序执行是低效的。因此事务处理的并发编程实现，保证最终结果没有冲突，与任何顺序执行事务时达到的结果相同。在这个例子中，这就意味着不管那个事务先发布，不论是先转账给另外一个人还是转移到支票账户成功了，另外一个操作就会失败。
所有事务处理系统的基本原则都一样。然而，术语可能因事务处理系统而异，下面使用的术语不一定通用。
事务处理系统通过在修改数据库时，记录数据库的中间状态来确保数据库完整性，然后如果一个事务无法提交，使用这些记录将数据库恢复到已知状态。
可以保留对数据库管理系统的所有修改的单独日志。这个对回滚并不需要，但在数据库发生故障时更新数据管理系统很有用，因此有些事务处理系统提供这个功能。如果数据库管理系统完全失败，则必须从最近的备份中恢复。备份不会反映自备份以来所提交的事务。但是，一旦数据库管理系统恢复了，就可以将日志应用于数据库（rollforward）以使数据库管理系统保持最新。
在一些情况下，两个事务可能在处理的过程中，同时尝试访问数据库的同一部分，从而阻止它们继续运行。例如，事务 A 访问了数据库的 X ，事务 B 访问了数据库的 Y。如果此时，事务 A 尝试访问数据库的 Y ，事务 B 尝试访问数据库的 X ， 则一个死锁（Deadlock）产生了，并且两个事务都不能继续下去。
事务处理系统旨在检测这些死锁何时发生。通常，两个事务都将被取消并回滚，然后它们将以不同的顺序自动再次启动，以便不再发生死锁。或者有些时候，只有其中的一个死锁事务将会被取消和回滚，在短暂的延迟后自动重启。
死锁可能涉及 3 个或更多的事务。涉及的事务越多，它们检测的难度就越大，因此事务处理系统可以检测到的死锁，在实际中是有限制的。
在提交和回滚机制不可用或不期望的系统中，补偿事务经常用来撤销失败的事务，并且将系统恢复到之前的状态。
Jim Gray 在 20 世纪 70 年代定义了一个可靠事务系统的特质，缩写为 ACID —— atomicity（原子性）、consistency（一致性）、 isolation（独立性）、durability（耐久性） 。
事务对状态的改变是原子的：要么全部发生，要么都不发生。
一个事务是状态的一种正确转换。作为一组采取的行为不违反跟状态相关的任何完整性的约束。
即使事务并发执行，对于每个事务 T ，其他事务看起来在 T 之前或 T 之后执行，但不是两者同时执行。
一旦事务成功完成（提交），它对数据库的更改，将在数据库失败后继续存在并保留其更改。
事务处理有下面的优点：
事务处理有下面的缺点：
目录
引子
最近看一些文章的时候，看到事务的概念，只记得在很早的时候接触过，想不起来有什么用，查询了资料后发现还是挺有用的。
介绍
事务处理（Transaction processing）是计算机科学中的信息处理，它被分成单个不可分割的操作，称为事务（transaction）。每个事务作为一个完整的单元必须成功或者失败，绝不可能部分完成。事务处理通过确保系统上相互依赖的操作，全部成功完成或者全部成功取消，在已知的一致状态上维持系统的完整性。
举个例子，一个典型的银行交易：将 100 从客户的储蓄账户转移到客户的支票账户。这个交易涉及至少 2 个独立的操作：借记储蓄帐户 100，记入支票账户 100。如果一个操作成功，另外一个操作失败，银行的账簿最后会不平衡。这里必须要有一个方式去保证所有操作都成功或都失败，这样在银行的整个数据库中才不会前后矛盾。
在事务中链接了多个操作时，确保所有的操作没有错误的完成，或者都失败。如果其中的一些操作完成但在尝试其它操作时发生了错误，则事务处理系统会“回滚（rolls back）” 事务的所有操作（包括已经成功的操作），从而消除事务的所有痕迹，并将系统恢复到处理事务开始之前所处的一致的已知状态。如果一个事务的所有操作都成功的完成，这个事务会被系统提交（committed），所有对数据库的更改将会是永久性的，一旦事务完成不能被回滚。
通常，事务是同时发布的，如果它们重叠，可能会产生冲突。例如一个客户的储蓄账户上有 150，尝试转账给另外一个人 100，同时转移 100 到支票账户，那么只有其中的一个可以成功。然而，强制事务按照顺序执行是低效的。因此事务处理的并发编程实现，保证最终结果没有冲突，与任何顺序执行事务时达到的结果相同。在这个例子中，这就意味着不管那个事务先发布，不论是先转账给另外一个人还是转移到支票账户成功了，另外一个操作就会失败。
方法
所有事务处理系统的基本原则都一样。然而，术语可能因事务处理系统而异，下面使用的术语不一定通用。
Rollback
事务处理系统通过在修改数据库时，记录数据库的中间状态来确保数据库完整性，然后如果一个事务无法提交，使用这些记录将数据库恢复到已知状态。
Rollforward
可以保留对数据库管理系统的所有修改的单独日志。这个对回滚并不需要，但在数据库发生故障时更新数据管理系统很有用，因此有些事务处理系统提供这个功能。如果数据库管理系统完全失败，则必须从最近的备份中恢复。备份不会反映自备份以来所提交的事务。但是，一旦数据库管理系统恢复了，就可以将日志应用于数据库（rollforward）以使数据库管理系统保持最新。
Deadlock
在一些情况下，两个事务可能在处理的过程中，同时尝试访问数据库的同一部分，从而阻止它们继续运行。例如，事务 A 访问了数据库的 X ，事务 B 访问了数据库的 Y。如果此时，事务 A 尝试访问数据库的 Y ，事务 B 尝试访问数据库的 X ， 则一个死锁（Deadlock）产生了，并且两个事务都不能继续下去。
事务处理系统旨在检测这些死锁何时发生。通常，两个事务都将被取消并回滚，然后它们将以不同的顺序自动再次启动，以便不再发生死锁。或者有些时候，只有其中的一个死锁事务将会被取消和回滚，在短暂的延迟后自动重启。
死锁可能涉及 3 个或更多的事务。涉及的事务越多，它们检测的难度就越大，因此事务处理系统可以检测到的死锁，在实际中是有限制的。
Compensating transaction
在提交和回滚机制不可用或不期望的系统中，补偿事务经常用来撤销失败的事务，并且将系统恢复到之前的状态。
ACID 标准
Jim Gray 在 20 世纪 70 年代定义了一个可靠事务系统的特质，缩写为 ACID —— atomicity（原子性）、consistency（一致性）、 isolation（独立性）、durability（耐久性） 。
Atomicity
事务对状态的改变是原子的：要么全部发生，要么都不发生。
Consistency
一个事务是状态的一种正确转换。作为一组采取的行为不违反跟状态相关的任何完整性的约束。
Isolation
即使事务并发执行，对于每个事务 T ，其他事务看起来在 T 之前或 T 之后执行，但不是两者同时执行。
Durability
一旦事务成功完成（提交），它对数据库的更改，将在数据库失败后继续存在并保留其更改。
优点
事务处理有下面的优点：
缺点
事务处理有下面的缺点：
参考资料