CAP理论学习
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
注意： ACID和BASE代表两种截然相反的设计哲学。ACID是传统数据库常用的设计概念，追求强一致性模型。BASE支持的大型分布式系统，提出通过牺牲强一致性获取高可用性 。
BASE是指基本可用、软状态、最终一致性。
- 基本可用（Basically Available）：是指分布式系统出现故障的时候，允许损失部分可用性，即保证核心可用。比如过年时使用微信红包的用户量剧增，为了保证核心的功能可用，微信可能会将一部分其他的功能禁用，这就是损失部分可用性的体现。
- 软状态（Soft State）：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的额延时就是软状态的体现。MySQL Replication的异步复制就是该状态的一种体现。
- 最终一致性（Eventual Consistency）：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
CAP的定义
Consistency 一致性
一致性指“all nodes see the same data at the same time” ，可分别从客户端和服务端两个不同的视角来理解。
服务端： 主要解决更新如何复制分布到整个系统，以保证数据最终一致性。
客户端 ：主要指的是多并发访问时更新过的数据如何获取的问题。
注意： 一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要结合考虑并发读写的场景 。多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性 。如果能容忍后续的部分或者全部访问不到，则是弱一致性。 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性 。
Availability 可用性
可用性指“reads all writes always succeed” ，即服务一直可用，而且是正常响应时间。好的可用性主要指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下和分布式数据冗余、负载均衡 等有着很大的关联。
Partition Tolerance 分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system” ，即分布式系统在遇到节点或者网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能正常运转满足系统需求，或者是机器之间网络异常，将分布式系统分隔为独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。
CAP理论取舍
- CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但是P是分布式系统不可避免的问题。传统的关系数据库满足CA
- CP without A：如果不要求A（可用性），相当于每个请求都需要Server之间强一致，而P（不允许分区）会导致同步时间无限延长，如此CP也是可以保证的，很多传统数据库分布式事务都属于这种模式。
- AP without C：如果要求A（可用性）和P（不允许分区），则需要放弃一致性。一旦分区发生，节点之间失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致。现在众多NoSQL都属于此类。
注意： CAP理论，只能根据场景定夺，适合的才是最好的。