关于ACID理论和CAP理论

参加某浪微博的校园招聘，由于自己不是很专注数据库方面的被问到这些，结果将CAP中的一致性和ACID中的一致性弄混淆了，特此总结下事务(Transaction):事务（Transaction）是并发控制的单位，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序。当对多个表进行更新的时候，某条执行失败。为了保持数据的完整性，需要使用事务回滚。

ACID:RDBMS中的四个要素

ACID是只指数据库中事务正确执行的四个要素的缩小，包含原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持久性(Durability)。一个支持事务(Transaction)的数据库必须，必须满足这四个特性,否则在事务过程(Transaction Processing)中无法保证数据的正确性
原子性(Atomicity)：
整个事务中的所有操作,要么全部完成，要么全部不完成，不可能停滞在中间某个阶段，事务执行过程中如果发生错误的话，会被会滚(Rollback)到事务开始之前的状态，就像这个事务从来没有执行过一样。
例子:
A给B转账100元



一致性(Consistency):
在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏。
隔离性(Isolation)：
隔离状态执行事务,使他们好像是系统在给定的时间内执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时成为成为串行化，为了防止事务操作间的混淆，必须串行化或者序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性(Durability):
在事务完成以后，该事务对数据库的操作便持久性的保持在数据库中，并不会回滚。

事务的（ACID）特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的。数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。　　数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。
目前主要有两种方式实现ACID：第一种是Write ahead logging，也就是日志式的方式。第二种是Shadow paging[b]CAP定理：[/b]CAP定理又称CAP原则，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP定理明确了分布式系统所能实现系统的局限性，目前互联网中的很多分布式系统是基于首要满足可用性和分区容忍性而设计的。 同时CAP原则是NoSQL数据库的基石，是NoSQL的理论基础。



Consistency（一致性）: 即数据一致性，简单的说，就是数据复制到了N台机器，如果有更新，要N机器的数据是一起更新的。 Availability（可用性）: 每个请求都能接受到一个响应，无论响应成功或失败Partition tolerance（分区容错性）: 在大规模分布式数据系统中，网络分区现象，即分区间的机器无法进行网络通信的情况是必然发生的，所以系统应该能够在这种情况下仍然继续工作。

在一系列的研究结果里发现，在较大型的分布式系统中，由于网络分隔，一致性与可用性不能同时满足，这意味着这三个要素只能同时实现两个，不可能三者兼顾；放宽一致性的要求会提升系统的可用性，提升一致性意味着系统需要牺牲一定的可用性。