什么是事务的acid性质

ACID，是指在数据库管理系统（DBMS）中事务所具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

在数据库系统中，一个事务是指由一系列数据库 *** 作组成的一个完整的逻辑过程。例如银行转帐，从原账户扣除金额，以及向目标账户添加金额，这两个数据库 *** 作的总和构成一个完整的逻辑过程，不可拆分。这个过程被称为一个事务，具有ACID特性。

1)原子性：

整个事务中的所有 *** 作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

比如说，一个事务开始更新100行记录，但是在更新了20行之后（因为某种原因）失败了，那么此时数据库会回滚（撤销）对那20条记录的修改。

2)一致性：

在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

事务将数据库从一个一致性状态带入另一个一致性状态。 比如说，在一个银行事务（在描述关系数据库事务的特性时，基本上都是用银行事务来作为描述对象的）中，需要从存储账户扣除款项，然后在支付账户中增加款项。 如果在这个中转的过程发生了失败，那么绝对不能让数据库只执行其中一个账户的 *** 作，因为这样会导致数据处于不一致的状态（这样的话，银行的账目上，借贷就不平衡了）。

如果数据库系统运行中发生故障，有些事物尚未完成就被迫中断了，系统就将此事务中对数据库的所有已经完成的 *** 作全部撤销，滚回到事务开始时的一致状态。

3)隔离性：

两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

这个特性是说，直到事务结束时（commit/rollback），其他事务（或者会话）对此事务所 *** 作的数据都不可见（但并不是说其他会话的读取会被阻塞）。 比如说，一个用户正在修改hremployees表，但是没有提交，那么其他用户在这个修改没有提交之前是看不到这个修改的。

4)持久性：

在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

被提交的更改会永久地保存到数据库中（并不是说以后就不可以修改）。 事务提交之后，数据库必须通过“恢复机制”来确保事务更改的数据不会丢失。

数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果

常用的一致性模型有：

a、严格一致性（,strict/atomicConsistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

b、顺序一致性（sequentialconsistency）：所有使用者以同样的顺序看到对同一数据的 *** 作，但是该顺序不一定是实时的。

c、因果一致性（causalconsistency）：只有存在因果关系的写 *** 作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。

d、管道一致性（PRAM/FIFOconsistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写 *** 作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中来的写 *** 作则无需保证顺序，就像一个一个的管道一样。相对来说比较容易实现。

e、弱一致性（weakconsistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的 *** 作具有顺序一致性，是全局可见的，且只有当没有写 *** 作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。

f、释放一致性（releaseconsistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区，释放一致性使用两个不同的 *** 作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了一个临界区，提供释放一致性也就意味着当release *** 作发生后，所有使用者应该可以看到该 *** 作。

作者 石默研

关于CAP的讨论已经很多，包括作者的另一篇文章“对CAP的初步解释”，基本已经即定思维的理解就是：分布式系统必须遵循CAP，一个分布式系统的设计只能同时满足其中两个，不可能同时满足；传统关系数据库选择A与C，代表了互联网新兴技术的NoSQL数据库则选择A与P（或者C与P，虽然这种情况其实需要详细讨论）。

但是，近年来，新兴的NewSQL数据库（TiDB或者OceanBase），则是一种在分布式环境下，保证的ACID强事务特征的强一致性数据库，并且很显然，它同时也满足了高可用性与优秀的分区可容忍性（很好的可扩展特性便是其一个层面的证明），似乎看起来，C、A、P都同时保证了，这不是违反了已经经过严格证明的CAP理论吗？

这个问题初看起来，似乎是比较神奇，但仔细分析，其实答案是很明显的。

首先，需要读者区分“分布式”与CAP中所提到的分区可容忍性Paritition Tolerance并不是一回事。分区可容忍性P是指以下两种分布式的情况：

同一份数据的多个副本的可分布性

有相互关联的数据的可分布性（ *** 作中表现为保证ACID的强分布式事务）

即使是分库分表，如果不存在以上两种情况，只是独立数据在同一个节点上的情况，虽然也是分布式，但跟CAP中的P没有半毛钱关系。

那么，还是回到上面的问题，NewSQL数据库，确实也是在保证了同一份数据多副本的强读写一致性、以及强分布式事务特性这样的C的情况下，同时保证了A与P呀！事实确实如此，但这还是要仔细分析：

无论是TiDB，还是OceanBase，其在保证数据多副本的强一致性时，都采用了Paxos协议或者Raft，它们简单来讲就是多数选举的原则，即写不需要全部副本都完成，就能保证读的强一致性，反过来也是一样。因此，其在分布式情况下，保证数据读写强一致性的效率还是很高的，就是说，在同一个数据中心的网络环境下，虽然这种分布可容忍性的满足理论上讲也会比单节点多一点点效率损失，但实际上是可以忽略不计的。但需要指出的是，在跨数据中心、跨城市的分布式情况下，如果要保证数据多副本的强一致性，即保证分区可容忍性，对效率（实际上是可用性A）的影响那还是不可忽略的。因此，在这种情况下，CAP理论依然成立。

再来看相互关联数据的可分布性，这就涉及到了分布式事务。现有的NewSQL数据库，即使在同一数据中心，为了保证强的分布式事务，对效率的折衷都是不可忽略的，所谓的乐观事务，只是因为客观问题本身冲突就少，并不改变冲突很多时效率明显受影响的现实。因此，NewSQL数据库虽然提供强分布式事务的能力，但在现实应用中，都是提倡尽量避免大量的分布式事务出现。如果你所遇到的应用场景是确实需要大量的分布式事务执行，又不做应用优化全交给数据库执行，那么，现有的NewSQL分布式数据库，依然会遇到明显的性能问题，其实就是可用性A降低了。同学仔细去研究应用中的实际情况就会发现，很多互联网应用，当其所需要的QPS很高很高，而对读写一致性与强分布式事务的要求又不那很高时候，其实，NewSQL数据库还是不能满足他们的需求的，他们仍然需要根据自己的情况改造或者选用NoSQL数据库，这也是CAP理论并没有被NewSQL打破的现实证明。

因此，总结来讲，NewSQL数据库，也是遵循CAP理论的，只不过，在同中心数据多副本情况下，保证P的同时对A的影响微乎其微；而在分布式事务的情况下，又采用了与应用特性相关的策略（其实乐观、悲观事务本质上就有根本应用特性区分的意思）来保证性能而已。当然，随着网络与计算机性能的提高，CAP三个特征中，保证其中两个，折衷另外一个，所带来的影响也会逐渐变小，但其理论依然是正确的。

以上就是关于什么是事务的acid性质全部的内容，包括:什么是事务的acid性质、数据库的acid中的一致性到底是什么意思、关于NewSQL数据库对于CAP的再解释等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！