一、BASE理论
BASE
BA: Basic Availability 基本业务可用性（支持分区失败）
S: Soft state 柔性状态（状态允许有短时间不同步，异步）
E: Eventual consistency 最终一致性（最终数据是一致的，但不是实时一致）
原子性（A）与持久性（D）必须根本保障
为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求
酸碱平衡(ACID-BASE Balance)
二、CAP定理
定理: 对于共享数据系统，最多只能同时拥有CAP其中的两个，没法三者兼顾。
任两者的组合都有其适用场景
真实系统应当是ACID与BASE的混合体
不同类型的业务可以也应当区别对待
结论：分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性
三、柔性事务
两阶段型
补偿型
异步确保型
最大努力通知型
四、柔性事务中的服务模式
可查询操作
幂等操作
TCC操作
可补偿操作
注：服务模式是柔性事务流程中的特殊操作实现（实现上对应业务服务要提供相应模式的功能接口），还不算是某一种柔性事务解决方案。
五、柔性事务中的服务模式：可查询操作
服务操作的可标识性
服务操作具有全局唯一标识
可以使用业务单据号（如订单号）
或者使用系统分配的操作流水号（如支付记录流水号）
或者使用操作资源的组合组合标识（如商户号+商户订单号）
操作有唯一的、确定的时间(约定以谁的时间为准)
单笔查询
使用全局唯一的服务操作标识，查询操作执行结果
注意状态判断，小心“处理中”的状态
批量查询
使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果
六、柔性事务中的服务模式：幂等操作
幂等性（Idempotenty）
f(f(x)) = f(x)
幂等操作
重复调用多次产生的业务结果与调用一次产生的业务结果相同
实现方式一
通过业务操作本身实现幂等性 (业务状态控制)
实现方式二
系统缓存所有请求与处理结果
检测到重复请求之后，自动返回之前的处理结果
七、柔性事务中的服务模式：TCC操作
Try: 尝试执行业务
完成所有业务检查(一致性)
预留必须业务资源(准隔离性)
Confirm:确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作要满足幂等性
Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作要满足幂等性
与2PC协议比较
位于业务服务层而非资源层
没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力
Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
较高开发成本
误区：很多人把两阶段型操作等同于两阶段提交协议2PC操作。其实TCC操作也属于两阶段型操作。
八、柔性事务中的服务模式：可补偿操作
do: 真正执行业务
完成业务处理
业务执行结果外部可见
compensate:业务补偿
抵销(或部分抵销)正向业务操作的业务结果
补偿操作满足幂等性
约束
补偿在业务上可行
由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控
（TCC操作中的Confirm操作和Cancel操作，其实也可以看作是补偿操作）
九、待续
分布式事务三
————————————————
版权声明：本文为CSDN博主「chenshiying007」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_27384769/article/details/79303074