从CAP到BASE（从零开始学区块链 47）
CAP理论告诉我们，一个分布式系统不可能同时满足
一致性（C：Consistency）
可用性（A：Availability）
分区容错性（P：Partition tolerance）
这三个基本需求，最多只能同时满足其中的两项
比较直观地理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其他人的确认就不应答，要么节点只能应答非一致的结果
好在大部分时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（大部分时候都是如此），要么牺牲掉可用性
既然不能同时满足三项需求，那么我们来看看，如果只满足其中两项时，我们来看一看分别拥有CA、CP和AP的情况。
首先来看看这几个需求的特征：
关注数据一致性（C）的特征，在分布式系统中的所有数据备份，在同一时刻是否同样的值，等同于所有节点访问同一份最新的数据副本
关注高可用性（A）的特征，在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求，对数据更新具备高可用性
关注分区容忍性（P）的特征：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
CA ：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA
CP：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
从以上的CAP优缺点我们可以看出，在设计区块链体系时，我们更应保证C和A之间的平衡，例如比特币需要更长时间的确认，牺牲部分P的性能，保证CA的优势，同时比特币通过共识算法，有较高的C容忍度（允许个别数据不一致情况），是在CAP三者中取得平衡的典范，如果我们设计一个新的区块链系统，可以根据具体应用场景，通过采纳不同的算法，实现不同应用类型的区块链
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，是由来自eBay的架构师Dan Pritchett在其文章BASE: An Acid Alternative注 中第一次明确提出的
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性(Strong consistency)，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性(Eventual consistency)
BASE三要素的定义
基本可用：是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但请注意，这绝不等价于系统不可用。
以下两个就是“基本可用”的典型例子。
响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1～2秒
功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致：性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
从BASE的三要素可以看出，以比特币的为代表的区块链技术，在CAP上取得的平衡更加接近BASE的设计目标，首先交易效率不是那么高，做到了基本可用；同时满足了较强的弱状态，经过特定数量的节点共识后交易即可完成，然后数据开始在链中同步，从而达到最终的一致性
其实就设计而言从来没有对错，只有真对特定场景的取舍，CAP充分说明中国文化中的“舍得”概念，您可以转发到群和朋友圈中让更多人了解，您的支持和鼓励是我最大的动力，喜欢就关注区块链大师吧
长按关注，了解更多