CAP 定理: 一个分布式系统最多只能同时满足一致性 (Consistence) 可用性 (Availability) 和分区容错性 (Partition tolerance) 这三项中的两项
一致性: 所有节点在同一时间的看到的数据相同
可用性: 读写永远都能成功, 即, 服务一直可用
分区容错性: 即使系统的某个分区遇到严重的故障, 系统能继续提供服务
CAP 中的权衡
根据 CAP 定理, 我们无法同时满足一致性可用性分区容错性这三个特性那么, 要舍弃哪个呢?
对于多数大型互联网应用的场景, 主机众多部署分散, 节点故障网络故障是常态, 必须保证 P; 应用的目的是提供服务, 因此通常也要保证 A 既然要保证 P 和 A, 就只能不同程度的舍弃 C, 牺牲一些用户体验严格来讲, 部分应用的 A 也不必保证 100%, 因此, 主流做法是首要保障 P 在 A 和 C 之间取舍重 A 轻 C
但是, 对于金融服务, 必须保证 C; 大规模金融服务几乎必然涉及网络分区, 所以也要保证 P; 为了保证 CP, 只能牺牲 A(停止服务)对于某些特殊的金融服务, 需要 7*24 小时提供服务, 则改为牺牲部分 P(如单节点主从备份, 故障切换), 保障 CA
BASE 定理
BASE 定理是对 CAP 定理的延伸: 即使无法做到强一致性(Strong Consistency), 但应用可以采用适合的方式达到最终一致性(Eventual Consitency)CAP 中提到的一致性是强一致性, 所谓牺牲一致性指牺牲强一致性保证弱一致性
BASE 是指基本可用 (Basically Available) 软状态 ( Soft State) 最终一致性( Eventual Consistency)
基本可用: 出现故障的时候, 允许损失部分可用性, 即, 保证核心可用
如, 电商大促时, 为了应对访问量激增, 部分用户可能会被引导到降级页面, 服务层也可能只提供降级服务
软状态: 允许系统存在中间状态, 而该中间状态不会影响系统整体可用性
软状态本质上是一种弱一致性, 允许的软状态不能违背基本可用的要求如, 分布式存储中一般一份数据至少会有三个副本, 允许不同节点间副本同步的延时(某些时刻副本数低于 3)
最终一致性: 系统中的所有数据副本经过一定时间后, 最终能够达到一致的状态
软状态的终极目标是最终一致性如, 分布式存储的副本数最终会达到稳定状态
ACID 和 BASE 的区别与联系
ACID 是事务的四个基本性质, 属于传统数据库常用的设计理念, 追求强一致性模型, 详见 事务的 ACID 和四个隔离级别 BASE 支持的是大型分布式系统, 提出通过牺牲强一致性获得高可用性(与分区容错性)
在分布式系统设计的场景中, 通常系统组件对一致性的要求不同, 对 ACID 和 BASE 的取舍也就不同
来源: http://www.tuicool.com/articles/FjqQBfR