CAP理论
- Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。即保证任意节点的数据内容一致
- Availability（可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
- Partition tolerance （分区容错性）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
它们的第一个字母分别是 C、A、P。
Eric Brewer 说，这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
注意：这里的三选二其实是有限制的：在分布式系统中P(分区容错性是一定要满足的），然后才是可以从A,C中选，即要么AP,要么CP，理论上分布式系统是不可能选择CA结构的
那么为什么理论上不可能出现CA尼？比如：如果系统出现分区，系统中的某个节点进行了写操作。为了保证C，那么就比如禁止其他节点的读操作，这就违反了A.如果要保证A,那么其他节点的读操作正常进行，那么就违反了C
总结
简述CAP定理内容
- 分布式系统节点通过网络来进行连接，呢么会出现分区问题（P）可能性就很大
- 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
-
- 如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
- 如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。
也就是说，在P一定会出现的情况下，A和C之间只能实现一个。
当没出现分区问题的话那么我们就需要尽可能去满足CA
如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以同时保证 C 和 A 了。因此，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。
2.1.1.一致性
Consistency（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致。
比如现在包含两个节点，其中的初始数据是一致的：
当我们修改其中一个节点的数据时，两者的数据产生了差异：
要想保住一致性，就必须实现node01 到 node02的数据 同步：
2.1.2.可用性
Availability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
如图，有三个节点的集群，访问任何一个都可以及时得到响应：
当有部分节点因为网络故障或其它原因无法访问时，代表节点不可用：
2.1.3.分区容错
Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
这时node02上的数据发生了更新，此时会将修改的数据同步到node01,但是node03中由于和2由于网络断开连接了，因此23数据就发生了不一致现象
Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务
2.1.4.矛盾
在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。
当节点接收到新的数据变更时，就会出现问题了：
如果此时要保证一致性，就必须等待网络恢复，完成数据同步后，整个集群才对外提供服务，服务处于阻塞状态，不可用。
如果此时要保证可用性，就不能等待网络恢复，那node01、node02与node03之间就会出现数据不一致。
也就是说，在P一定会出现的情况下，A和C之间只能实现一个。
总结
简述CAP定理内容
- 分布式系统节点通过网络来进行连接，一定会出现分区问题（P）
- 当分区出现时，系统的一致性（C）和可用性（A）就无法同时满足
2.2.BASE理论
基本思想
BASE理论是对CAP的一种解决思路，包含三个思想：
- Basically Available （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
基本可用性的理解：
什么叫允许损失部分可用性呢？
- 响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
- 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
软状态（Soft State)
软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性（Eventually Consistent）
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
分布式一致性的 3 种级别：
- 强一致性：系统写入了什么，读出来的就是什么。（一般保证强一致性可以考虑加锁同步操作）
- 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
- 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
2.3.解决分布式事务的思路
分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：
- AP模式（最终一致性思想）：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
- CP模式（强一致性）：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。即各个分支事务执行完业务后先别提交，等待彼此结果，之后再做统一提交
但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。
对于分布式事务解决框架Seata使用
参考分布式事务
