概述
分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。分布式系统的最大难点，就是各个节点的状态如何同步。CAP、BASE定理是这方面的基本定理，也是理解分布式系统的起点。
CAP理论
一致性（Consistency）：所有节点同一时间看到是相同的数据
可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应
分区容错性（Partition tolerance）：系统任意分区后，在网络故障时，仍能操作
CAP理论指出：CAP三者最多只能取其二，不可兼得
image
-
CAP常见模型
- CA模型
image
- 举例：
- 单站点数据库
- 集群数据库
- LDAP
- xFS 文件系统
- 实现方式：
- 两阶段提交
- 缓存验证协议
-
CP模型
image
- 举例
- 分布式数据库
- 分布式锁
- 绝大部分协议
- 实现方式
- 悲观锁
- 少数分区不可用
- AP 模型
image
- 举例：
- Coda
- Web 缓存(nosql数据库)
- DNS
- 实现方式
- 到期/租赁
- 解决冲突
- 乐观锁
- CA模型
BASE理论
BASE是Basiclly Available(基本可用)，Soft state(软状态)，Eventually consistent(最终一致性)三个短语的缩写。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
- Basiclly Available
基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。基本可用的两个例子:
- 响应事件上的损失:正常情况下，一个在线搜索引擎需要再0.5秒之内返回给用户响应的查询结果，但由于出现故障，查询结果的响应时间增加到了1~2秒
- 功能上的损失:正常情况下，在一个电子商务网站上进行购物，消费者能够顺利完成每一笔订单，但是在一些节目大促销高峰，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级的页面
Soft state
弱状态也被称为软状态，和硬状态对应，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统不同节点的数据副本之间进行数据同步的过程存在延时Eventually consistent
最终一致性强调的是系统所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要试试保证系统数据的强一致性。在实际工程实践中，最终一致性存在以下五类主要变种:
- 因果一致性(Causal consistency):如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对数据项的访问都应该能够或得到进程A更新后的最新值，并且如果进程B要对改数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的显示。
- 读己之所写(Read your write):指进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的值旧。因此读己之所写，也是一种特殊的因果一致性。
- 会话一致性(Session consistency):会话一致性将对系统数据的访问过程框定在了一个会话中，系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更新操作之后，客户端能够在一个会话中始终读取到改数据项的最新值。
- 单调读一致性(Monotonic read consistency):读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
- 单调写一致性(Monotonic write consistency):单调写一致性:一个系统需要能够保证来自同一个进程的写操作被顺利的执行。
- 总结
BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它完全不同于ACID 的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在同一段时间内是不一致的，但最终达到一致的状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用
