在系统架构时，应该根据具体的业务场景来权衡CAP。比如，对于大多数互联网应用来说（如门户网站），因为机器数量庞大，部署节点分散，网络故障是常态的，可用性是必须保证的，所以只有舍弃一致性来保证服务的AP。而对于银行等需要确保一致性的场景，通常会权衡CA和CP模型，CA模型网络故障时完全不可用，CP模型具备部分可用性。
Eric Brewer在2012年发表文章指出了CAP里面“三选二”的做法存在一定的误导性。主要体现在以下3个方面。
·由于分区很少发生，那么在系统不存在分区的情况下没什么理由牺牲C或A。
·C与A之间的取舍可以在同一系统内以非常细小的粒度反复发生，而每一次的决策可能因为具体的操作，乃至因为牵涉特定的数据或用户而有所不同。
·这3种性质都可以在一定程度上衡量，并不是非黑即白的有或无。
可用性显然是在0%~100%连续变化的，一致性分很多级别，连分区也可以细分为不同含义，如系统内的不同部分对于是否存在分区可以有不一样的认知。
理解CAP理论最简单的方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，但这又会导致丧失P性质。一般来说跨区域的系统，设计师无法舍弃P性质，那么就只能在数据一致性和可用性上做一个艰难选择。不确切地说，NoSQL运动的主题其实是创造各种可用性优先、数据一致性其次的方案，而传统数据库坚守ACID特性，做的是相反的事情。
BASEBASE（Basically Available、Soft state、Eventual consistency）来自互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来的，核心思想是即便不能达到强一致性（Strong Consistency），但可以根据应用特点采用适当的方式来达到最终一致性（Eventual Consistency）的效果。BASE是对CAP中C和A的延伸。BASE的含义如下。
·Basically Available：基本可用。
·Soft state：软状态/柔性事务，即状态可以有一段时间的不同步。
·Eventual consistency：最终一致性。
BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性、柔性和可靠性，并要求达到最终一致性。
本文给大家讲解的内容是分布式系统开发实战： 数据一致性， CAP的意义及发展- 下篇文章给大家讲解的是分布式系统开发实战：数据一致性，以数据为中心的一致性模型；
- 觉得文章不错的朋友可以转发此文关注小编；
- 感谢大家的支持!
