目录
在计算机领域，如果是初入行就算了，如果是多年的老码农还不懂 CAP 定理，那就真的说不过去了。CAP可是每一名技术架构师都必须掌握的基础原则啊。
现在只要是稍微大一点的互联网项目都是采用 分布式 结构了，一个系统可能有多个节点组成，每个节点都可能需要维护一份数据。那么如何维护各个节点之间的状态，如何保障各个节点之间数据的同步问题就是大家急需关注的事情了。
CAP定理是分布式系统中最基础的原则。所以理解和掌握了CAP，对系统架构的设计至关重要。
一、CAP定理
什么是 CAP？
「 CAP定理 」又被称为 布鲁尔定理，它提出对于一个分布式系统而言，不能同时满足以下三点：
- Consisteny（一致性）
- Availability（可用性）
- Partition tolerance（分区容错性）
也就是说CAP定理指明了，任何分布式系统只能同时满足这三项中的两项。
如上图，如果是最多同时满足两项，那我们可以有三个组合：CA、CP、AP。在聊这三个组合之前，我们先分别看一下 Consisteny（一致性）、Availability（可用性）、Partition tolerance（分区容错性）的含义。
假设某个系统当前有两个节点A和B，两个节点分别可以由Actor进行读写，两个节点之间的数据会自动完成同步。
Consisteny（一致性）
一致性的要求是指，对于任何客户端（上图Actor）来说，每次的读操作，都能获得最新的数据。即，当有客户端向A节点写入了新数据之后，其它客户端从B节点中进行读操作所获得的数据必须也是最新的，是与A节点数据保持一致的。
Availability（可用性）
可用性的要求是指，每个请求都能在合理的时间内获得符合预期的响应（不保证获取的结果是最新的数据）。
按照上图来看就是，客户端只要向A节点或B节点发起请求后，只要这两个节点收到了请求，就必须响应给客户端，但不需要保证响应的值是否正确。
Partition tolerance（分区容错性）
分区容错性是指，当节点之间的网络出现问题之后，系统依然能正常提供服务。
讲完了C、A、P的含义和要求，我们继续来看看它们之间如何组合使用。
CAP 怎么应用？
先把视野回到这张图上：
虽然我们知道有 CA、CP、AP 三种组合方式，但是在分布式系统的结构下，网络是不可能做到100%可靠的。既然网络不能保证绝对可靠，那 P（分区容错性）就是一个必选项了。原因如下：
如果选择 CA组合，放弃 P（分区容错性）。还是以最上面的图中A和B节点来举例，当发生节点间网络故障时，为了保证 C（一致性），那么就必须将系统锁住，不允许任何写入操作，否者就会出现节点之间数据不一致了。但是锁住了系统，就意味着当有写请求进来的时候，系统是不可用的，这一点又违背了 A（可用性）原则。
因此分布式系统理论上是不可能有CA组合的，所以我们只能选择 CP 和 AP组合架构。
下面我们来详细看一下 CP架构 和 AP架构的特点：
CP 架构
CP架构即 Consisteny（一致性）与 Partition tolerance（分区容错性）的组合。
如上图，由于网络问题，节点A和节点B之前不能互相通讯。当有客户端（上图Actor）向节点A进行写入请求时（准备写入Message 2），节点A会不接收写入操作，导致写入失败，这样就保证了节点A和节点B的数据一致性，即保证了Consisteny（一致性）。
然后，如果有另一个客户端（上图另一个Actor）向B节点进行读请求的时候，B请求返回的是网络故障之前所保存的信息（Message 1），并且这个信息是与节点A一致的，是整个系统最后一次成功写入的信息，是能正常提供服务的，即保证了Partition tolerance（分区容错性）。
上述情况就是保障了CP架构，但放弃了Availability（可用性）的方案。
AP 架构
AP架构即 Availability（可用性）与 Partition tolerance（分区容错性）的组合架构。
如上图，由于网络问题，节点A和节点B之前不能互相通讯。当有客户端（上图Actor）向节点A进行写入请求时（准备写入Message 2），节点A允许写入，请求操作成功。但此时，由于A和B节点之前无法通讯，所以B节点的数据还是旧的（Message 1）。当有客户端向B节点发起读请求时候，读到的数据是旧数据，与在A节点读到的数据不一致。但由于系统能照常提供服务，所以满足了Availability（可用性）要求。
因此，这种情况下，就是保障了AP架构，但其放弃了 Consisteny（一致性）。
CAP 注意事项？
了解了CAP定理后，对于开发者而言，当我们构建服务的时候，就需要根据业务特性作出权衡考虑，哪些点是当前系统可以取舍的，哪些是应该重点保障的。
即使是在同一个系统中，不同模块的数据可能应用的CAP架构都是不同的。举个例子，在某个电商系统中，属于用户模块的数据（账密、钱包余额等）对一致性的要求很高，就可以采用CP架构。而对于一些商品信息方面的数据对一致性要求没那么高，但为了照顾用户体验，所以对可用性要求更高一些，那么这个模块的数据就可以采用AP架构。
另外，虽然上面第二节讲到过我们只能选择CP和AP，无法选择CA。但这句话成立的前提条件是在系统发生了网络故障的情况下。然而，网络故障的概率在系统的整个生命周期中占比是很小的，因此我们在设计的时候，虽然要考虑网络问题下的方案，但也要考虑网络正常情况下的方案，即在网络正常情况下，CA是可以实现的，我们也需要去保证在绝大多数时间下的CA架构。
再者，即使我们按照CAP定理，三个中只能取其二，但不代表我们只需要保障其中的两点，而完全的放弃第三点，我们应该为不能保障的第三点也做一些防备措施或者冗余方案，来使系统更加的完善健全。
二、BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。
- 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
- 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
软状态
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据听不的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
亚马逊首席技术官Werner Vogels在于2008年发表的一篇文章中对最终一致性进行了非常详细的介绍。他认为最终一致性时一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够胡渠道最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟，系统负载和数据复制方案设计等因素。
在实际工程实践中，最终一致性存在以下五类主要变种。
- 因果一致性：
因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。
- 读己之所写：
读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者而言，其读取到的数据一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。
- 会话一致性：
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
- 单调读一致性：
单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
- 单调写一致性：
单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。
以上就是最终一致性的五类常见的变种，在时间系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性的分布式系统。事实上，可以将其中的若干个变种相互结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才设计的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。在同步方式中，数据的复制国耻鞥通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么狠显然，从备库中读取的的数据将是旧的，因此就出现了不一致的情况。当然，无论是采用多次重试还是认为数据订正，关系型数据库还是能搞保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性使相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。
小结
计算机系统从集中式向分布式的变革随着包括分布式网络、分布式事务和分布式数据一致性等在内的一系列问题与挑战，同时也催生了一大批诸如ACID、CAP和BASE等经典理论的快速发展
---------------------
原文：https://blog.csdn.net/jsjwk/article/details/88567898 ，https://www.cnblogs.com/wangzhongqiu/p/7267218.html
9万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
