CAP定理

Consistency 一致性（强一致性）

强一致性，要求更新过的数据能被后续的访问都能看到

若一致性，能容忍后续的部分或者全部访问不到

最终一致性，经过一段时间后要求能访问到更新后的数据

Avaliability 可用性（只要收到用户请求，服务器必须给出回应）
Partition tolerance 分区容错（区间通信可能失败）

CAP定理-1.png

CAP定理-2.png

BASE理论

Basically Available（基本可用）

假设系统出现了不可预知的故障，但还是能用，相比较正常的系统而言；

Soft state（软状态）

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种硬状态。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

Eventually consistent（最终一致性）

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态。因此所有客服端对系统的数据访问最终都能够获取到最新的值。

分布式事务解决方案

1. 基于XA协议的两阶段提交

分布式事务处理的XA规范-1

XA规范中分布式事务有AP，RM，TM组成：

AP（应用程序 Application Program）：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。

RM（资源管理器 Resource Manager）：RM管理计算机共享的资源，许多软件都可以去访问这些资源，资源包含比如数据库，文件系统，打印机服务器等。

TM（事务管理器Transaction Manager）:负责管理全局事务，分配事务唯一标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。

二阶段协议：
第一阶段TM要求所有RM准备提交对应的事务分支，询问RM是否有能力保证成功的提交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就对工作内容进行持久化，并给TM回执OK；否则给TM回执NO。RM在发送了否定答复并回滚了已经的工作后，就可以丢弃这个事务分支信息了。
第二阶段TM根据阶段1各个RM Perpare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交，如果有RM prepare回执No的话，则TM通知所有RM回滚自己的事务分支。

也就是TM与RM之间是通过两阶段提交协议进行交互的。
优点：尽量保证了数据的强一致性，适合对数据强一致性要求很高的关键领域（金融领域）。（其实也不能百分百保证强一致）
缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

2. TCC补偿机制

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它氛围三个阶段：

Try 阶段主要是对业务系统做检测及资源预留

Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

Cancle 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
TCC补偿机制
例如：A要向B 转账，思路大概是：
我们有一个本地方法，里面依次调用

1.首先在Try阶段，要先调用远程接口把B和A的钱冻结起来。

2.在Confirm阶段，执行远程调用的转账的操作，转账成功进行解冻。

3.如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法（Cancle）。

优点： 相比两阶段提交，可用性比较强
缺点： 数据的一致性要差一些。TCC属于应用曾的一种补偿方式，所以需要程序员在实现的适合多谢很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

3. 消息最终一致性

消息最终一致性.png

基本思路：
消息生产方，需要额外建立一个消息表，并记录消息发送状态。消息表和业数据谁要在一个事务里提交，也就是说他们要在一个数据库里面，然后消息会经过MQ发送到消息的消费方，如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行，如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍，如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

优点： 一种非常典型的实现，避免了分布式事务，实现了最终一致性。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。