CAP理论
-
CAP三个字母分别代表分布式系统中的三个相互矛盾的属性:
-
Consistency(C:一致性)：CAP理论中的副本一致性特指强一致性。
-
Availiablity（A:可用性）：指系统在出现异常时已经可以提供服务。
-
Tolerance to the partition of network（P:分区容忍）：指系统可以对网络分区这种异常情况进行容错处理。
-
CAP理论指出：无法设计一种分布式协议，使得同时完全具备CAP三个属性。高可用、数据一致性是很多系统设计的目标，分区又不可避免。
-
CA without P:
-
两阶段提交
-
缓存验证协议
-
单站点数据库
-
集群数据库(同构数据库，分布式数据库为异构数据库)
-
LDAP（轻量目录访问协议）
-
xFS 文件系统
-
如果不要求P（不允许分区），则C（强一致性）和A(可用性)是可以保证的。分区始终存在，CA系统更多的要求是允许分区后的子系统依然保持CA。
-
如果希望能够避免系统出现分区容错性问题，一种较为简单的做法是将所有的数据（或者仅仅是哪些与事务相关的数据）都放在一个分布式节点上。这样做虽然无法100%保证系统不会出错，但至少不会碰到由于网络分区带来的负面影响。但同时需要注意的是，放弃P的同时也就意味着放弃了系统的可扩展性
-
举例：
-
实现方式：
-
CP without A:
-
悲观锁
-
少数分区不可用
-
分布式数据库
-
分布式锁定
-
绝大部分协议
-
如果不要求A（可用），相对于每个请求都需要在Server之前强一致性，而P（分区）会导致同步时间的无限延长，如此CP也是可用保证的，很多传统数据库分布式事务都属于这种模式。
-
一旦系统遇到网络分区或其他故障或为了保证一致性时，放弃可用性，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用。
-
举例：
-
实现方式：
-
AP without C：
-
到期/租赁
-
解决冲突
-
乐观
-
Coda
-
Web 缓存
-
DNS
-
要求高可用并允许分区，则放弃一致性。一旦分区发生节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性，众多的NoSQL都属于这种。
-
这里所说的放弃一致性，实际上指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统无法保证数据保持实时的一致性，但是能够承诺的是，数据最终会达到一个一致的状态。
-
举例：
-
实现方式：
BASE理论
-
BASE是Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）三个短语的简写。
-
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性。接下来，我们着重对BASE中的三要素进行讲解。
-
基本可用
-
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。一下就是两个”基本可用”的例子。
-
响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
-
功能上的损失：正常情况下，在一个电子商务网站（比如淘宝）上购物，消费者几乎能够顺利地完成每一笔订单。但在一些节日大促购物高峰的时候（比如双十一、双十二），由于消费者的购物行为激增，为了保护系统的稳定性（或者保证一致性），部分消费者可能会被引导到一个降级页面，如下：
-
软状态
-
软状态是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同的数据副本之间进行数据同步的过程存在延时。
-
最终一致性
-
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
-
最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据到达一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。
-
在实际工程实践中，最终一致性存在一下五类主要变种。
-
因果一致性(Causal consistency)
-
读己之所写(Read your writes)
-
会话一致性(Session consistency)
-
单调读一致性(Monotonic read consistency)
-
单调写一致性(Monotonic write consistency)
-
以上就是最终一致性的五种常见的变种，在实际系统实践中，可以将其中的若干个变种互相结合起来，以构建一个具有最终一致性特性的分布式系统。事实上，最终一致性并不是只有那些大型分布式系统才涉及的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中（比如MySQL和PostgreSQL），大多都会采用同步或异步方式来实现主备数据复制技术。在同步方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致。而在异步方式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间传输的时间长短。如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，因此就出现了数据不一致的情况。当然，无论是采用多次重试还是人为数据订正，关系型数据库还是能够保证最终数据达到一致，这就是系统提供最终一致性保证的经典案例。
