强一致性解决方案
2PC（同步短事务）
阶段1：提交事务请求（投票阶段）
阶段2：执行事务提交（commit、rollback）
3PC
阶段1：是否提交
阶段2：预先提交
阶段3：提交（commit、rollback）
最终一致性解决方案
TCC（同步短事务）
TCC模式将一个任务拆分三个操作：Try、Confirm和Cancel（业务入侵性强）。
在TCC模式中，主业务服务负责发起流程，而从业务服务提供TCC模式的Try、Confirm和Cancel三个操作，还有一个事务管理器的角色负责控制事务的一致性。如图：
可靠性消息事件
如图：
1、服务A发送正向消息并将消息落库sending，发送消息成功改为sended。
2、服务B收到消息处理，有两种情况：
a.成功，回逆向消息。
b.异常或者处理失败，不回消息。
3、服务A收到逆向消息，将消息置为success
4、定时任务定时检查sended的消息，并通过自定义规则（例如：发送时间，处理时间等判定）判定sended已失败并重发。
这里大家肯定有疑问，手动确认消息失败重发不是一样吗？
事实上在分布式不发环境中一般建议如此，如果某个服务出现异常消息一直重发，最终会拖垮消息队列导致整个集群出现异常（个人观点）。
saga模式(异步长事务)
协同式saga（没有协调者）
如图：
1、请求到订单系统完成创建，订单系统发消息减库存。
2、库存系统此时有两种情况
a.扣库存成功，发消息到支付系统。
b.扣库存失败，触发补偿机制，发消息到订单系统。
3、支付系统也有两种情况
a.支付成功，创建订单成功。
b.支付失败，触发补偿机制，减库存，创建订单失败。
编排式协同式saga（拥有统一的协调者，协调者需要做ha）
如图：
流程跟协同式类似。
开源产品
ServiceComb Pack
ServiceComb Pack架构 整个架构分为三个部分，一个是Alpha（支持HA）协调器（支持多个实例提供高可用支持），另外一个就是注入到微服务实例中的Omega，以及Alpha与Omega之间的交互协议， 目前ServiceComb Pack支持Saga 以及TCC两种分布式事务协调协议实现。
Omega包含了与分析用户分布式事务逻辑相关的 事务注解模块（Transaction Annotation） 以及 事务拦截器（Transaction Interceptor）； 分布式事务执行相关的事务上下文（Transaction Context），事务回调（Transaction Callback) ，事务执行器 （Transaction Executor）；以及负责与Alpha进行通讯的事务传输（Transaction Transport）模块。
分布式Saga、TCC模式
链接：servicecomb.apache.org/cn/docs/dis… (没有什么比官方文档更好了0.0)
seata(2pc、XA的优化)
seata架构
seata分布式事务是由一批分支事务组成的全局事务，通常分支事务只是本地事务。
Seata有3个基本组成部分：
事务协调器（TC，支持HA）：维护全局事务和分支事务的状态，驱动全局提交或回滚。
事务管理器TM：定义全局事务的范围：开始全局事务，提交或回滚全局事务。
资源管理器（RM）：管理分支事务正在处理的资源，与TC进行对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。
Seata管理的分布式事务的典型生命周期：
TM要求TC开始一项新的全球交易。TC生成代表全局事务的XID。
XID通过微服务的调用链传播。
RM将本地事务注册为XID到TC的相应全局事务的分支。
TM要求TC提交或回退XID的相应全局事务。
TC驱动XID对应的全局事务下的所有分支事务以完成分支提交或回滚。
seata支持AT、TCC、SAGA 和 XA 事务模式
AT（目前常用模式）
注意：AT对补偿机制的异常没有做很好的处理，例如seata的AT模式，如果回滚失败无法重试，只能通过告警，人工介入。
phase 1(pre)
phase 2 (commit)
phase 2 (rollback)
如需想详细了解：seata.io/
cadence（workflow）
Cadence是一个分布式，可伸缩，持久且高度可用的编排引擎，以可伸缩和弹性方式执行异步长时间运行的业务逻辑。
cadence中主要有三种角色：
Activity：活动 | 任务 | 处理器handler | 微服务 | actor | 分支事务执行者
workflow：工作流 | 编排流程 | 分布式事务执行流程（支持长短事务）
Starter：工作流启动
cadence Activity
1、支持运行任何应用程序代码。
2、支持长期运行任务，用heartbeat保持状态。
3、支持异步执行。
4、根据设置的重试策略自动重试。
5、支持路由到指定的主机或进程。
6、通过队列派遣任务执行。
7、支持对worker进行限流。
8、支持对queue进行限流。
workflow
1、支持虚拟对象技术。
2、支持事务。
3、对活动（activities）进行编排。
4、支持接收外部事件并作出相应。
5、有状态（包含局部变量和栈）。
6、支持长期运行。
7、支持持久化的时钟。
架构
matching service匹配服务（任务派遣）：接收history service的活动或者是决策任务，存储在taskstorage中，然后将任务派遣给匹配的activity或者workflow worker去执行
history service：接收starter的启动工作流指令然后调度决策或者是活动任务，它也接收来自activity或者是workflow这些worker的执行响应，根据响应结果再调度新的决策或者是活动任务继续分发给matching service去做任务派遣、history service将工作流执行的任务步骤记录在workflow storage中，执行过程中发生的事件记录在events storage,它也会将工作流执行的状态信息记录在visibility storage中。
fornt end service它相当于是一个facade门面服务，屏蔽内部服务的复杂性，提供简单友好的api。
短事务样例：
长事务saga样例：
cadence web ui
值得一提的cadence支持查看事务执行过程中调用细节查看
其他详细信息详见：cadenceworkflow.io
参考
github.com/uber/cadenc…
cadenceworkflow.io/
seata.io/
servicecomb.apache.org/
《高可用可伸缩微服务架构：基于Dubbo、Spring Cloud和Service Mesh》
