一、BASE理论
1. BA: Basic Availability 基本业务可用性（支持分区失败）；
2. S: Soft state 柔性状态（状态允许有短时间不同步，异步）；
3. E: Eventual consistency 最终一致性（最终数据是一致的，但不是实时一致）；
4. 原子性（A）与持久性（D）必须根本保障；
5. 为了可用性、性能与降级服务的需要，只有降低一致性( C ) 与 隔离性( I ) 的要求；
6. 酸碱平衡(ACID-BASE Balance)；
二、CAP定理
定理: 对于共享数据系统，最多只能同时拥有CAP其中的两个，没法三者兼顾。
任两者的组合都有其适用场景；
真实系统应当是ACID与BASE的混合体；
不同类型的业务可以也应当区别对待；
结论：分布式系统中，最重要的是满足业务需求，而不是追求抽象、绝对的系统特性。
三、柔性事务
1. 两阶段型
2. 补偿型
3. 异步确保型
4. 最大努力通知型
四、柔性事务的服务模式
可查询操作
幂等操作
TCC操作
可补偿操作
注：服务模式是柔性事务流程中的特殊操作实现（实现上对应业务服务要提供相应模式的功能接口），还不算是某一种柔性事务解决方案。
五、柔性事务的服务模式：可查询操作
服务操作的可标识性：
1、服务操作具有全局唯一标识
可以使用业务单据号（如订单号）
或者使用系统分配的操作流水号（如支付记录流水号）
或者使用操作资源的组合组合标识（如商户号+商户订单号）
2、操作有唯一的、确定的时间(约定以谁的时间为准)
单笔查询
3、使用全局唯一的服务操作标识，查询操作执行结果
4、注意状态判断，小心“处理中”的状态
批量查询
5、使用时间区段与(或)一组服务操作的标识，查询一批操作执行结果
六、柔性事务的服务模式：幂等操作
幂等性（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操作，其实也可以看作是补偿操作）
九、柔性事务解决方案：可靠消息最终一致（异步确保型）
实现
业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送。
消息
业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。
约束
被动方的处理结果不影响主动方的处理结果， 被动方的消息处理操作是幂等操作。
成本
可靠消息系统建设成本
一次消息发送需要两次请求，业务处理服务需实现消息状态回查接口
优点、适用范围
消息数据独立存储、独立伸缩，降低业务系统与消息系统间的耦合
对最终一致性时间敏感度较高，降低业务被动方实现成本
用到的服务模式
可查询操作、幂等操作
方案特点
兼容所有实现JMS标准的MQ中间件
确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）。
行业应用案例
支付宝、eBay（BASE）、去哪儿
十、柔性事务解决方案：TCC（两阶段型、补偿型）
实现
一个完整的业务活动由一个主业务服务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务服务提供TCC型业务操作
业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。
成本
实现TCC操作的成本
业务活动结束时confirm或cancel操作的执行成本
业务活动日志成本
适用范围
强隔离性、严格一致性要求的业务活动
适用于执行时间较短的业务（比如处理账户、收费等业务）
用到的服务模式
TCC操作、幂等操作、可补偿操作、可查询操作
方案特点
不与具体的服务框架耦合（在RPC架构中通用）
位于业务服务层，而非资源层
可以灵活选择业务资源的锁定粒度
TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）。
行业应用案例
支付宝XTS（蚂蚁金融云的分布式事务服务DTS）
十一、柔性事务解决方案：最大努力通知（定期校对）
实现
业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失。
业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息。
约束
被动方的处理结果不影响主动方的处理结果
成本
业务查询与校对系统的建设成本
适用范围
对业务最终一致性的时间敏感度低
跨企业的业务活动
用到的服务模式
可查询操作
方案特点
业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）。
主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知。
主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息。
行业应用案例
银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对账文件）
十二、常用分布式事务解决方案
1、刚性事务
全局事务（标准的分布式事务）
2、柔性事务
可靠消息最终一致（异步确保型）
TCC （两阶段型、补偿型）
最大努力通知（非可靠消息 、定期校对）
纯补偿型
往期回顾：
