系统架构师知识：什么是CAP

相关推荐

系统架构师知识：什么是CAP

　　CAP、BASE理论是当前在互联网领域非常流行的NoSQL的理论基础。那么什么是CAP呢?我们一起来了解一下!

系统架构师知识：什么是CAP

　　1、什么是CAP

　　著名的CAP理论是由Brewer提出的，所谓CAP，即一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)。

　　(1)、Consistency(一致性)：更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致(All nodes see the same data at the same time)。

　　这里的一致性，一定要和传统的RDBMS中的事务一致性区分开。

　　在传统的RDBMS中，事务具有ACID4个属性，即原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)和持久性(Durable)。

　　ACID是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。

　　a、原子性(Atomicity)：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。

　　b、一致性(Consistency)：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性;事务结束时，所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。

　　c、隔离性(Isolation)：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。

　　d、持久性(Durability)：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

　　MIT的Gilbert和Lynch在证明CAP的过程中改变了Consistency的概念，也就是将Consistency转化为Atomic。Gilbert认为这里所说的Consistency其实就是数据库系统中提到的ACID的另一种表述：一个用户请求要么成功、要么失败，不能处于中间状态(Atomic);一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态(Consistent);未完成的事务不会互相影响(Isolated);一旦一个事务完成，就是持久的(Durable)。

　　(2)、Availability(可用性)：读和写操作都能成功(Reads and writes always succeed)。

　　可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果，所有的请求都能“成功”拿到对应的响应。

　　(3)、Partition Tolerance(分区容错性)：在出现网络故障导致分布式节点间不能通信时，系统能否继续服务(The system continues to operate despite arbitrary message loss or failure of part of the system)。

　　直观感受就是系统中节点crash或者网络分片都不应该导致一个分布式系统停止服务。

　　2、如何证明CAP?

　　CAP的证明很简单：

　　假设两个节点集{G1, G2}，由于网络分片导致G1和G2之间所有的通讯都断开了。

　　如果在G1中写，在G2中读刚写的数据， G2中返回的值不可能是刚刚在G1中的写值。

　　对于分布式数据系统而言，分区容错性(Partition Tolerance)是基本要求，否则就不称其为分布式系统。

　　由于可用性(Availability)的要求，G2一定要返回这次读请求，因为分区容错性(Partition Tolerance)的存在，导致一致性(Consistency)一定是不可满足的。

　　CAP理论告诉我们，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，三个要素中最多只能同时满足两点。

　　显然,任何横向扩展策略都要依赖于数据分区，软件架构通常必须在一致性(Consistency)与可用性(Availability)之间做出选择。

　　3、CAP的延伸BASE

　　BASE是Basically Available、Soft state、Eventually consistent三个词组的简写，是对CAP中C 和A的延伸。

　　(1)Basically Available：基本可用，即数据一致性能够基本满足二八定律，即至少保证80%一致性，剩下20%就不要过于纠结。

　　(2)Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步。

　　在不过分追求数据一致性(强一致性)前提下可考虑软状态策略，例如把数据(State)缓存在客户端一段时间，在一段时间过后，如果客户端没有再次刷新状态的请求的话，就清除此缓存(Soft)，这个状态就会消失。

　　(3)Eventual consistency：最终一致性，即在某一段短时间内允许数据不一致，但经过一段较长时间(这里的一段时间多数是业务能够容忍的延迟)，等所有节点上数据的拷贝都整合在一起的时候，数据会最终达到完全一致。我用自己的经验和亲身实践证明，最终一致性贯穿着互联网尤其是电子商务类型的主要应用的生命周期。

　　BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong Consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性。

【系统架构师知识：什么是CAP】相关文章：

系统架构师的知识和职责08-20

系统架构师是干什么的08-17

系统架构师概述11-07

系统架构师的岗位职责是什么（通用12篇）08-29