分布式领域CAP理论

• Consistency 一致性： 数据一致更新，所有数据变动都是同步的。
• Availability 可用性：好的响应性能，但往往一致性要求越高的系统，可用性越低。
• Partition tolerance 分区容错性：可靠性，分区之后也能够保证集群的只能正常行使，往往是分布式系统中必须保证的一点；

定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：

• Atomicity 原子性：一个事务中所有操作都必须全部完成，要么全部不完成。
• Consistency 一致性：在事务开始或结束时，数据库应该在一致状态。
• Isolation 隔离层：事务将假定只有它自己在操作数据库，彼此不知晓。
• Durability 持久性：一旦事务完成，就不能返回。

跨数据库事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。

CAP原则能否三者同时满足

解析：

1. 如果CA满足看P是否能满足？
2. 如果AP满足看C是否能满足？
3. 如果CP满足看A是否能满足？

如果CA满足看P是否能满足？

我们来分析：当C（Consistency）一致性A（Availability）可用性都满足时会发生什么？为了保持数据的一致性，数据在各个节点间同步需要花费时间，同时保证服务可用意味着服务器的数量不能过多，因为过多就会导致数据同步时间过长，而导致超时触发熔断降级机制，这与可用性相悖。但是如果要满足容错的话就必须是多节点，而多节点意味着同步数据同步时间必定过长，这两无法做到同时满足所以就导致了情况1是无法满足。

如果AP满足看C能否满足？

我们来分析：当A（Availability）可用性和P（Partition tolerance）分区容错性都满足的情况下会发生什么？服务器多节点部署，导致服务器数量剧增，同时需要保证服务节点可用，这就说明服务节点与节点之间的调用时间无法过长，否则就会导致服务节点不可用。如果在这种情况下，满足C（Consistency）一致性，就会出现服务器因同步数据而导致浪费大量的时间，导致服务器不可用（超过了规定时间范围），所以当AP满足时是无法同时满足C的。

如果CP满足看A是否能满足？

我们来分析：当C（Consistency）一致性和P（Partition tolerance）分区容错性都满足时，这个时候的服务器情况是怎么样的？必定是数量多并且为了保证数据同步大量的服务器节点会进入“超长待机”状态，此时如果再让服务满足A（可用性）的话，就会出现大部分的服务节点不可用，线程池被挤爆，然后整个项目宕机。所以情况3是无法满足的。

如何抉择/取舍？

一般来讲P（容错性）是一定要满足的，其他可以根据项目需求选择A或者C。
就目前市场来说，CP更加符合金融类项目，AP更加适合商城类项目。

BASE模型反ACID模型

完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：

• Basically Available 基本可用。支持分区失败(e.g. sharding碎片划分数据库)
• Soft state 软状态 状态可以有一段时间不同步，异步。
• Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有：

• 按功能划分数据库
• Sharding碎片

BASE思想主要强调基本的可用性，如果你需要High可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在NOSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1、Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2、领域模型 + 分布式缓存 + 存储，可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。