事务
我们先学习事务是什么，事务的特点是什么？
什么是事务？
由一组操作构成的可靠，独立的工作单元
什么是ACID？
ACID是事务4个重要的特性，其内容分别是：
（1）Atomicity：原子性
指的是事务是不可分割的，要么都成功，要么都失败
（2）Consistency：一致性
指的是事务操作完成之后数据的总量并没有发生变化，举个简单的例子，A和B转账，A给B转账100，A的账户减少100，B的账户增加100，如果A转账失败，B的账户就不会增加，事务操作前后，二者的钱总数是不变的，这就是一致性
（3）Isoolation：隔离性
指的是事务与事务之间是独立操作的，互相不干扰
（4）DurDurability：持久性
指的是事务一旦提交对数据库的改变就是永久的
本地事务
我们一般情况下操作的事务都应该是本地事务，本地事务就是由资源管理器（如DBMS）本地管理。
- 本地事务的优点
（1）支持严格的ACID属性
（2）可靠
（3）高效
（4）状态可以只在资源管理器中维护
（5）应用编程模型简单 - 本地事务的缺点：
（1）不具备事务的分布式处理能力
（2）隔离的最小单位由资源管理器决定，如数据库中的一条记录。
注意一点:
（1）本地事务是在单个数据库的本地并且限制在单个进程内的事务。
（2）本地事务不涉及多个数据来源。
了解了本地事务，现在让我们了解下真正的分布式事务相关知识点。
全局事务（DTP模型）-- 标准分布式事务
-
全局事务
事务由全局事务管理器全局管理，不再是各自的服务管理各自的了 -
事务管理器
管理全局事务状态与参与的资源，协同资源的一致提交/回滚 -
TX协议
应用或者应用服务器与事务管理器的接口 -
XA协议
全局事务管理器与资源管理器的接口
（1）XA是由X/Open组织提出的分布式事务的规范。XA规范主要定义了（全局）事务管理器（TM）和（局部）资源管理器（RM）之间的接口。主流的关系型数据库产品都实现了该XA接口。
（2）XA接口是双向的系统接口，在事务管理器（TM）以及一个或多个资源管理器（RM）之间形成通信桥梁。
（3）XA之所以需要引入事务管理器是因为，在分布式系统之中，从理论上讲两台机器无法到达一致的状态，需要引入一个单点进行协调。
（4）由全局事务管理器管理和协调的事务，可以跨越多个资源（如数据库或者JMS）和进程。全局事务管理器一般使用XA二阶段提交协议与数据库进行交互。 -
AP
也就是应用程序，可以理解为DTP的程序 -
RM
资源管理器，这里可以是一个DBMS，或者消息服务器管理系统，应用程序通过资源管理器对资源进行控制，资源必须实现XA定义的接口。 -
TM
事务管理器，负责协调和管理事务，提供给AP应用程序编程接口以及管理资源管理器 -
总结：
事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源。
两阶段提交
- 准备操作ACID
A：原子性，准备之后，仍然可以回滚
C：一致性，准备时，一致性必须是正常的（返回ok）
I：独立性，准备后，事务结果仍然只在事务内可见
D：持久性，事务结果已经持久
（1）两阶段提交协议是XA用于在全局事务中协调多个资源的机制。
（2）事务管理器（TM）和资源管理器（RM）之间采取两阶段提交的方案来解决一致性问题。
（3）两阶段提交需要一个协调者（TM）来掌控所有参与者节点（RM）的操作结果并且指引这些节点是否需要最终提交。
BASE理论
- BASE
（1）BA：Basic Avaliablity基本业务可用性（支持分区失败）
（2）S: Soft state 柔性状态（状态允许有短时间不同步，异步）
（3）E: Eventual consistency最终一致性（最终数据是一致的，但是不是实时的一致） - 原子性和持久性必须根本保证
- 为了可用性，性能与降级服务的需要，只能降低一致性和隔离性的要求
- 酸碱平衡（ACID-BASE Balance）
CAP理论
- 对于共享的数据系统，最多只能存在CAP三个特性的其中两个特性。没有办法三个都兼顾
例如：Eureka保证AP Zookeeper保证CP - 任意两者的组合都有他们各自的适用场景
- 真实系统应该是ACID和BASE的混合体
- 不同类型的业务应当区别对待
- 结论：
分布式系统中，最重要的是满足业务需求，而不是追求抽象，绝对的系统特性。
柔性事务
该事务与刚性事务相对（强满足ACID）
柔性事务是我们关注的重点：
（1）两阶段型
（2）补偿型
（3）异步确保型
（4）最大努力通知型
柔性事务中的服务模式
服务模式是柔性事务流程中的特殊操作实现（实现上对应业务服务要提供相应模式的功能接口），还不算是某一种柔性事务解决方案
柔性事务中的服务模式有以下几种：
（1）可查询操作
（2）幂等操作
（3）TCC操作
（4）可补偿操作
可查询操作
- 服务操作的可标识性
服务操作具有全局唯一标识
就是说需要id等作为唯一标识，一个标识只能查出一条记录
操作有唯一的，确定的时间（约定时间为准） - 单笔查询
使用全局唯一的服务操作标识，查询操作执行的结果
注意状态判断，小心"处理中"的状态 - 批量查询
支持批量查询
幂等操作
简而言之，幂等操作其实就是对于用一个数据操作多次，结果是一致的
- 实现方式
（1）通过业务操作本身实现幂等操作
（2）系统缓存所有的请求与处理的结果
（3）检测到重复请求之后，自动返回之前的处理结果
TCC操作
- Try ：尝试执行业务
（1）完成所有业务检查（一致性）
（2）预留必须业务资源（准隔离性） - Confirm：确认执行业务
（1）真正执行业务
（2）不做任何业务检查
（3）只使用try阶段预留的业务资源
（4）confirm操作要满足幂等需求 - Cancel：取消执行业务
（1）释放Try阶段预留的业务资源
（2）Cancel操作要满足幂等操作
可补偿操作
- do：真正执行业务
（1）完成业务处理
（2）业务执行结果外部可见 - compensate：业务补偿
（1）抵消（或者部分抵消）正向业务操作的业务结果
（2）补偿操作满足幂等操作 - 约束
（1）补偿在业务上执行
（2）由于业务执行结果未进行隔离，或者补偿不完整带来的风险与成本可控
TCC操作的Confirm操作和Cancel操作，其实也可以看做是补偿。
柔性事务解决方案： 可靠消息最终一致（异步确保型）
- 实现
业务处理服务在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有得到确认发送指令后，实时消息服务才真正的发送。 - 消息
业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或者回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。 - 约束
被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作 - 成本
（1）可靠消息系统建设成本
（2）一次消息发送需要两次请求，业务处理服务需要实现消息状态回查接口 - 优点，适用范围：
（1）消息数据独立存储，独立伸缩，降低业务系统与消息系统间的耦合
（2）对最终一致性时间敏感度较高，降低业务被动方实现成本 - 方案特点
（1）兼容所有实现JMS标准的MQ中间件
（2）确保业务数据可靠的前提下，实现业务数据的最终一致（理想状态下基本是准实时一致）
柔性事务解决方案：TCC（两阶段型，补偿型）
- 实现
（1）一个完整的业务活动由一个主业务服务与若干从业务组成
（2）主业务服务负责发起并完成整个业务活动
（3）从业务服务提供TCC型业务操作
（4）业务活动管理器控制业务活动的一致性，他登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有的TCC型操作的cancel操作。 - 成本
（1）实现TCC操作的成本
（2）业务活动结束的时confirm和cancel操作的成本
（3）业务活动日志的成本 - 适用范围
（1）强隔离性，严格一致性要求的业务活动
（2）适用于执行时间较短的业务（处理账户，收费业务） - 方案特点
（1）不与具体的服务框架耦合（RPC架构中通用）
（2）位于业务服务层，而非资源层
（3）可以灵活的选择业务资源的锁定粒度
（4）TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好，可以说是为了独立部署SOA服务而设计的
柔性事务解决方案：最大努力通知（定期校对）
- 实现
（1）业务活动的主动方，在完成业务处理后，向业务活动的被动方发送消息，允许消息丢失。
（2）业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息 - 约束
被动方的处理结果不影响主动方的建设成本 - 成本
业务查询与校对系统的建设成本 - 适用范围
（1）对业务最终一致性的时间敏感度低
（2）跨企业的业务活动 - 方案特点：
（1）业务活动的主动方在完成业务处理后，向业务活动被动方发送通知消息（允许消息丢失）
（2）主动方可以设置时间阶梯型通知规则。在通知失败后按照规则重复通知，直到通知N次以后不再通知
（3）主动方提供校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息
总结
- 刚性事务
全局事务（标准的分布式事务） - 柔性事务
（1）可靠消息最终一致（异步确认型）
（2）TCC（两阶段型，补偿型）
（3）最大努力通知（非可靠消息，定期校对）