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