事务处理系统的ACID属性及状态详解

（一）事务处理的ACID属性

当事务处理系统创建事务时，将确保事务有某些特性。组件的开发者们假设事务的特性应该是一些不需要他们亲自管理的特性。这些特性称为ACID特性。ACID就是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabilily）。

1.原子性

原子性属性用于标识事务是否完全地完成，一个事务的任何更新都要在系统上完全完成，如果由于某种原因出错，事务不能完成它的全部任务，系统将返回到事务未开始的状态。

让我们再看一下银行转账的例子。如果在转账的过程中出现错误，整个事务将会回滚。只有当事务中的所有部分都成功执行了，才将事务写入磁盘并使变化永久化。

为了提供回滚或者撤消未提交的变化的能力，许多数据源采用日志机制。例如，SQL Server使用一个预写事务日志，在将数据应用于（或提交到）实际数据页面前，先写在事务日志上。但是，其他一些数据源不是关系型数据库管理系统（RDBMS），它们管理未提交事务的方式完全不同。只要事务回滚时，数据源可以撤消所有未提交的改变，那么这种技术应该可用于管理事务。

2.一致性

事务在系统完整性中实施一致性，这通过保证系统的任何事务最后都处于有效状态来实现。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。因为事务开始时系统处于一致状态，所以现在系统仍然处于一致状态。

再让我们回头看一下银行转账的例子，在账户转换和资金转移前，账户处于有效状态。如果事务成功地完成，并且提交事务，则账户处于新的有效的状态。如果事务出错，终止后，账户返回到原先的有效状态。

记住，事务不负责实施数据完整性，而仅仅负责在事务提交或终止以后确保数据返回到一致状态。理解数据完整性规则并写代码实现完整性的重任通常落在开发者肩上，他们根据业务要求进行设计。

当许多用户同时使用和修改同样的数据时，事务必须保持其数据的完整性和一致性。

3.隔离性

在隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。

重要的是，在隔离状态执行事务，系统的状态有可能是不一致的，在结束事务前，应确保系统处于一致状态。但是在每个单独的事务中，系统的状态可能会发生变化。如果事务不是在隔离状态运行，它就可能从系统中访问数据，而系统可能处于不一致状态。通过提供事务隔离，可以阻止这类事件的发生。(www.xing528.com)

在银行的示例中，意味着在这个系统内，其他过程和事务在我们的事务完成前看不到我们的事务引起的任何变化，这对于终止的情况非常重要。如果有另一个过程根据账户余额进行相应处理，而它在我们的事务完成前就能看到它造成的变化，那么这个过程的决策可能建立在错误的数据之上，因为我们的事务可能终止。这就是说明了为什么事务产生的变化直到事务完成才对系统的其他部分可见。

隔离性不仅仅保证多个事务不能同时修改相同数据，而且能够保证事务操作产生的变化直到变化被提交或终止时才能对另一个事务可见，并发的事务彼此之间毫无影响。这就意味着所有要求修改或读取的数据已经被锁定在事务中，直到事务完成才能释放。大多数数据库，例如SQL Server以及其他的RDBMS，通过使用锁定来实现隔离，事务中涉及的各个数据项或数据集使用锁定来防止并发访问。

4.持久性

持久性意味着一旦事务执行成功，在系统中产生的所有变化将是永久的。应该存在一些检查点防止在系统失败时丢失信息。甚至硬件本身失败，系统的状态仍能通过在日志中记录事务完成的任务进行重建。持久性的概念允许开发者认为不管系统以后发生了什么变化，完成的事务是系统永久的部分。

在银行的例子中，资金的转移是永久的，一直保持在系统中。这听起来似乎简单，但这依赖于将数据写入磁盘，特别需要指出的是，在事务完全完成并提交后才写入磁盘。

所有这些事务特性，不管其内部如何关联，仅仅是保证从事务开始到事务完成，不管事务成功与否，都能正确地管理事务涉及的数据。

（二）事务的状态

一个事务开始运行后，其结果如何是难以预测的。为了保障系统赋予事务的ACID特性，必须记载事务的状态，供DBMS（Database Management System）分析和处理。

（1）事务开始（begin-transaction）：开始执行，进入活跃状态。

（2）事务操作（operating）：事务进行一系列的操作，仍处于活跃状态。

（3）事务结束（end-transaction）：事务完成了所有读、写操作，执行完最后一个语句。从用户看，事务似乎已完成它的使命。但从系统看，事务的工作虽已完成，但它产生的结果是否全部保存下来，尚不得而知。此时事务进入部分提交状态（partially committed）。

（4）事务失败（abort）：事务在进行某些读写操作后出现异常情况，不能继续下去或部分交付之后要求撤消其操作结果，则进入失败状态，这种事务必须回滚。

（5）事务交付（commit-transaction）：事务完成了所有读、写操作。系统已保存或承诺保存该事务的所有操作结果，此时事务进入交付状态。

（6）事务终止（terminated）：事务交付或事务撤消后进入终止状态。系统运行时从此开始忘记该事务。