ACID和CAP的比较

https://www.jdon.com/artichect/acid-cap.html

1 简介

　　事务机制ACID和CAP理论是数据管理和分布式系统中两个重要的概念，很不巧，这两个概念中都有相同的“C”代表 "Consistency" 一致性，但是实际上是完全不同的意义，下面是比较两个概念的不同之处。

2 什么是ACID

2.1 简介

　　事务的定义和实现一直随着数据管理的发展在演进，当计算机越来越强大，它们就能够被用来管理越来越多数据，最终，多个用户可以在一台计算机上共享数据，这就导致了一个问题，当一个用户修改了数据而另外一个还在使用旧数据进行计算过程中，这里就需要一些机制来保证这种情况不会发生。

　　ACID规则原来是在1970被Jim Gray定义，ACID事务解决了很多问题，但是仍然需要和性能做平衡协调，事务越强，性能可能越低，安全可靠性和高性能是一对矛盾。

　　一个事务是指对数据库状态进行改变的一系列操作变成一个单个序列逻辑元操作，数据库一般在启动时会提供事务机制，包括事务启动 停止 取消或回滚。

　　但是上述事务机制并不真的实现“事务”，一个真正事务应该遵循ACID属性，ACID事务才真正解决事务，包括并发用户访问同一个数据表记录的头疼问题。

2.2 定义

• Atomic原子性: 一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全部完成要么一个也不会完成，如果事务过程中任何一点失败，将要被改变的数据库记录就不会被真正被改变。
• Consistent一致性: 数据库的约束 级联和触发机制Trigger都必须满足事务的一致性。也就是说，通过各种途径包括外键约束等任何写入数据库的数据都是有效的，不能发生表与表之间存在外键约束，但是有数据却违背这种约束性。所有改变数据库数据的动作事务必须完成，没有事务会创建一个无效数据状态，这是不同于CAP理论的一致性"consistency".
• Isolated隔离性: 主要用于实现并发控制, 隔离能够确保并发执行的事务能够顺序一个接一个执行，通过隔离，一个未完成事务不会影响另外一个未完成事务。
• Durable持久性: 一旦一个事务被提交，它应该持久保存，不会因为和其他操作冲突而取消这个事务。很多人认为这意味着事务是持久在磁盘上，但是规范没有特别定义这点。

3 什么是CAP

3.1 简介

　　CAP是分布式系统中进行平衡的理论，它是由 Eric Brewer发布在2000年。

3.2 定义

• Consistent一致性: 同样数据在分布式系统中所有地方都是被复制成相同。
• Available可用性: 所有在分布式系统活跃的节点都能够处理操作且能响应查询。
• Partition Tolerant分区容错性: 在两个复制系统之间，如果发生了计划之外的网络连接问题，对于这种情况，有一套容错性设计来保证。

3.2.1 一致性和可用性

　　如下图，一个分布式系统。它的数据在A、B两个服务有相同的备份。

　　客户端1请求A，要把一条数据50W改为5000，那么它需要通知B也去把这条数据改为5000，保证数据的一致性。这就是所谓的一致性。

　　那么要怎么操作呢

　　方案：

　　　　A在实施修改之前，就广播通知B也修改，A在改，B也在改(不管是A还是B，在改的时候锁住，不让其它线程读写)，等B改好了，通知A，A收到B修改成功的通知后，才返回给客户，这个请求才算完成。这样子就能保住数据的强一致性。

　　　在同步数据的时候，是要加锁的，必然会导致可用性的降低。这就是一致性和可用性的冲突所在。

　　　如果对数据一致性要求没这么高，就可以同步的时候不加锁，只要最终A和B数据能同步就好(也就是最终一致性)，那么在同步的过程中，就可能读取A和读取B的数据不一致。但是这样子可用性就会增强。

3.2.2 分区容错性

　　分布式系统，各个服务交互、同步都是通过网络来实现的。

　　但是网络又是可能存在这样那样的问题。比如说，网线被老鼠咬断了。

　　网络出现问题就会导致交互出现问题。

　　这是客观存在的事实，我们无法改变。所以在设计系统的时候，要考虑到这个问题，使得系统能够容忍网络错误带来的一系列问题。这就是分区容错性。

3.3 CAP和ACID一致性区别

　　ACID一致性是有关数据库规则，如果数据表结构定义一个字段值是唯一的，那么一致性系统将解决所有操作中导致这个字段值非唯一性的情况，如果带有一个外键的一行记录被删除，那么其外键相关记录也应该被删除，这就是ACID一致性意思。事务就是一致性的体现。

　　CAP理论的一致性是保证同样一个数据在所有不同服务器上的拷贝都是相同的，这是一种逻辑保证，而不是物理，因为光速限制，在不同服务器上这种复制是需要时间的，集群通过阻止客户端查看不同节点上还未同步的数据维持逻辑视图

3.4 CAP的局限性

　　而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

　　分布式架构的时候必须做出取舍。

　　一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向。

3.5 CAP的取舍

　　1）CA： 传统Oracle数据库

　　2）AP： 大多数网站架构的选择

　　3）CP： Redis、Mongodb