An introduction to distributed transactions
1. Classic case of transfer
The transfer business across regions and institutions is very common in real life, and the basic process is as follows:
Account 01 transfers money to account 02 through a series of service and payment processes. During this process, if account 01 is successfully debited, but account 02 is not credited, this will result in inconsistent data and violate basic business principles . Based on the data belonging to different services and different databases, transaction errors in this case are called distributed transaction problems.
2. Basic Concepts
Distributed transaction means that transaction participants, transaction-supporting servers, resource servers, and transaction managers are located on different nodes of different distributed systems.
In the above transfer case, it seems that there is only one transfer operation, but in fact it consists of multiple detailed operations of different services and different databases. These imperceptible detailed operations are distributed in different services, and even belong to different regions and applications. How to ensure All these operations succeed or all fail, that is, to ensure data consistency between different databases, which is the core problem that distributed transactions need to solve.
3. Distributed transaction features
Based on the following e-commerce business scenarios, the basic distributed architecture idea:
- The database is divided into databases and tables based on business characteristics;
- Database splitting, followed by business as a service (SOA);
Splitting based on e-commerce business, there will be common ones: order, user, inventory, logistics and a series of services, managing different business databases, in the actual order payment application scenario, it is necessary to operate users, orders, and inventory at the same time. When waiting for multiple services, data consistency must be ensured, order payment is successful, and distributed transactions must be used for inventory.
2. The basic theory of CAP
1. Basic introduction
When it comes to distributed transaction issues, it is inevitable to talk about the CAP theory, the three major indicators of distributed systems:
Consistency: Consistency
A single transaction performs an update and write operation, and the operation returns successfully after the operation. The data read by other transactions at the same time is completely consistent, and there is no intermediate state. Described in a distributed system: users place an order to pay, deduct money, reduce inventory, and generate logistics, which must be consistent. For example, in the limited discount promotion, the inventory does not decrease after the user places an order, which leads to inconsistencies.
Availability: Availability
The service must always be available, and the server must respond within a limited time to the user's request, regardless of whether the result is successful or unsuccessful.
Partition tolerance: partition fault tolerance
通俗说，在分布式系统中，一个流程里可能出现某个服务出错情况，这是无法绝对避免的，在程序设计上要能容忍这种错误发生。
2、CP和AP模式
分布式系统很难同时满足一致性、可用性、分区容错性三个特点，在大部分的系统架构中，都会选择CP或者AP模式，即需要抛弃一个特点，说明一点，为何P没有抛弃，对于分布式系统而言，分区容错是该架构模式下的基本原则，不同的SOA服务和数据库是比如会被部署到不同的节点下。所以如何解决C（一致性）和A（可用性）就成分布式系统的最大痛点。
为何不能同时满足C和A，这也是基于分布式架构特点看，不同服务直接不能保证通信是100%成功，一旦出现失败情况，一致性和可用性就无法满足。
既然强一致性无法保证，那退一步，给处理时间，最后结果保证一致性，也可以，这就涉及到BASE理论。
三、BASE基础理论
1、基础简介
BASE理论是由eBay公司的架构师提出的，主要是对上述的CAP理论中一致性和可用性做的权衡结果，基于CAP定律逐步演化而来，核心思想；即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当策略实现数据的最终一致性。
Basically Available：基本可用
分布式系统在发生故障的时，允许损失部分可用性。例如常见电商清仓甩卖时，为保证主业务可以，一些不重要的服务直接降级提示。
Soft State：软状态
允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种硬状态。
Eventual Consistency：最终一致
强调的数据更新操作，即软状态必须有个时间期限，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。时间期限长短取决于延时、负载、数据同步等各种因素。
BASE理论提出是基于大规模高可用可扩展的分布式系统架构，不同于关系型数据库事务特点(ACID)的强一致性模型，通过牺牲强一致性来获取更高的可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。实际的业务场景下事物(ACID)基本特性和BASE理论也是要权衡考虑。
2、柔性事务
遵循BASE理论，利用业务特点，在指定期限内让事务保持最终一致性，柔性事务是一种思想，从根本上看，就是业务模式对于事务过程中不一致性有一定的容忍度，可以留出足够的时间执行事务最终一致的方法。
3、PAXOS算法
Paxos算法一种保障分布式系统最终一致性的共识算法，利用的是选举策略，少数服从多数的思想。PAXOS不要求对所有节点做实时同步，实质上是考虑到了分区情况下的可用性，通过减少完成一次事务需要的参与者个数，来保障系统的可用性。
例如：N个服务节点，有(N/2)+1个节点达成共识，则认为系统达到了一致，并且按照Paxos原则，最终理论上也达到了一致，不会再改变，如此一来，只要保证有半数以上的服务存活，允许小部分服务挂掉，客户可以与大部分服务节点通信，那么就不会影响整体操作流程，也不需确保服务器全部处于工作状态，容错性非常好。操作影响的数据和结果随后会被异步的同步到其他节点上，从而保证最终一致性。
四、电商场景分析
1、场景描述
分布式事务在业务系统中是十分常见的，最经典的场景就是电商架构中的交易业务，如图：
客户端通过请求订单服务，执行下单操作，实际上从订单服务上又触发了多个服务链请求，基本步骤如下：
- 客户端请求在订单服务上创建订单；
- 订单服务调用账户服务扣款；
- 订单服务调用库存服务执行库存扣减；
- 订单通过物流服务，转化为物流运单；
这套流程在电商系统中是基本业务，在实际的开发中远比这里描述的复杂。
2、服务时序图
上述1中是业务性的流程概念描述，从系统开发层面，在微服务的架构模式下，通常的时序流如下：
这样服务间的通信时序图在程序设计中十分常见，在分布式系统中，清楚的描述各个服务间的通信流程是十分关键的。
上图描述的交易流程是在最理想的状态下，各个服务都执行成功，但是程序是不能100%保证一直正常，经常出现如下情况：
- 服务间通信失败；
- 单个节点服务宕掉；
- 服务接口执行失败；
这些都是实际开发中经常出现的问题，比如订单创建成功，扣款成功，但是库存扣减失败，物流运单生成，那么这笔订单该如何处理？这就是分布式事务要解决的核心问题。
分布式事务机制要保证不同服务之间形成一个整体性的可控的事务，业务流程上的服务除非全部成功，否则任何服务的操作失败，都会导致所有服务上操作回滚，撤销已经完成的动作。
五、TCC基础概念
1、分段提交协议
XA是一个分布式事务协议，大致分为两部分：事务管理器和本地资源管理器，本地资源管理器基本由数据库实现，大多数关系型数据库都实现XA接口，而事务管理器作为全局事务的调度者，负责整个事务中本地资源的提交和回滚，基本原理如下：
阶段1：事务询问
事务管理器向所有的参与事务的资源管理器发送确认请求，询问是否可以执行事务提交操作，并等待各参与者的响应，如果执事务操作成功，就反馈给事务管理器表示事务可以执行，如果没有成功执行事务，就反馈事务不可以执行；
阶段2：事务提交
XA根据第一阶段每个资源管理器是否都准备提交成功，判断是要事务整体提交还是回滚，正式执行事务提交操作，并在完成提交之后释放整个事务占用的资源；事务也会存在失败情况，导致流程取消回滚；
XA事务具有强一致性，在两阶段提交的整个过程中，一直会持有资源的锁，性能不理想的缺点很明显，特别是在交易下单链路中，往往并发量很高，XA无法满足该类高并发场景。
2、TCC概念简介
Try(预处理)-Confirm(确认)-Cancel(取消)模式的简称TCC。
Try阶段
业务检查(一致性)及资源预留(隔离)，该阶段是一个初步操作，提交事务前的检查及预留业务资源完成；例如购票系统中的占位成功，需要在15分钟内支付；
Confirm阶段
确认执行业务操作，不在执行任何业务检查，基于Try阶段预留的业务资源，从理想状态下看只要Try成功，Confirm也会成功，因为资源的检查和锁定都已经成功；该阶段出现问题，需要重试机制或者手动处理；购票系统中的占位成功并且15分钟内支付完成，购票成功；
Cancel阶段
Cancel阶段是在业务执行错误需要回滚到状态下执行分支事务的取消，预留资源的释放；购票系统中的占位成功但是15分钟内没有支付，取消占位；
3、TCC对比XA
XA事务的强一致性，导致资源层的锁定；
TCC在业务层面追求最终一致性，不会长久占用资源；
六、分段事务分析
现在回到模块一中的场景案例，在理想状态下流程全部成功是好的，但实际情况是突发情况很多，基于TCC模式分析上述电商的具体业务：
1、资源预留
在TCC模式下，通常表字段的状态设计思路为：订单(支付中.已支付.取消订单)，账户(金额.冻结金额)，库存(库存.冻结库存)，物流(出库中.已出库，已撤回)，这种状态管理在开发中非常常见。
所以在TCC模式里通常会如下处理资源预留：
假设订单总额为：200，状态：支付中，则此时资源预留情况如下：
- tc_account账户表：tc_total=1000，tc_ice=200，总金额1000，冻结200；
- tc_inventory库存表：tc_total=100，tc_ice=20，总库存100件，冻结20件；
- tc_waybill运单表：tc_state=1，运单状态，出库中；
这样下单链路上的相关资源已检查并且预留成功；
2、资源提交确认
资源预留成功之后，执行资源提交执行：
- tc_account账户表：tc_total=800，tc_ice=0，即订单扣款成功；
- tc_inventory库存表：tc_total=80，tc_ice=0，库存消减成功；
- tc_waybill运单表：tc_state=2，运单状态，已出库；
这样下单链路上的相关资源已全部提交处理成功，这是最理想的状态；
3、失败回滚
整个过程是可能执行失败的，或者用户直接自己发起回退，则要回滚整个链路上的数据：
- tc_account账户表：tc_total=1000，tc_ice=0，取消账户冻结的200；
- tc_inventory库存表：tc_total=100，tc_ice=0，取消库存冻结的20件；
- tc_waybill运单表：tc_state=3，运单状态，已撤回；
这样下单链路上的相关数据都基于该笔订单做回退操作，恢复；
4、补偿机制
整个电商交易流程，不管是成功，还是完整的回退失败，都是需要在理想状态下，要求整个服务链路和数据是绝对正常的才行。但是在实际分布式架构下是很难保证的，所以在产品的设计上会预留很多操作入口，用来手动做事务补偿或回退操作：
大型复杂的业务系统中，直接修改数据库通常情况下是不允许的，一般核心流程会预留各种操作入口，用来处理突发状况，弥补数据的完整性，例如交易链路上，只要扣款成功，后续的数据无论如何都会补上，是不允许回滚的，当然如果没有扣款成功，订单有效期结束，该笔交易也就算做结束。
通过电商交易的案例，和TCC模式的概念，描述了分布式事务的流程和处理思路，在开发时通常会选择现有的分布式组件来具体实现事务控制。
七、最大努力通知
TCC分段提交适用分布式架构中对一致性、实时性要求较高的业务场景，在实际业务中也存在实时性比较低的业务，例如常见的短信通知，客户端消息，运营体系更新等业务，这时候为了减轻核心流程的复杂度和压力，可以采取最大努力通知方式实现柔性事务的管理。
例如常见的第三方支付业务中，本地业务和支付端业务处理完成之后都会生成消息通知，基本流程如下：
- 本地业务预处理完成之后；
- 请求第三方支付服务；
- 支付操作成功对该账号发送消息；
- 支付服务回调本地业务；
- 本地业务生成系统通知消息；
上述流程的消息场景中有一些基础特点，在核心业务处理完成之后，发送消息通知，允许失败，在指定时间段内或者指定重试次数之后，允许消息丢失情况存在，即消息的不可靠性。
在实际的支付系统中，启动每日对账校验时会对当日的流水做校验，如果发现支付流水有未完成的流程，会有状态弥补，后续可以继续处理，这种手段在对账中很常用。
八、可靠消息
分布式事务基于可靠消息最终一致性的实现方案，既然是可靠消息，则要求MQ必须支持事务管理，这样才能保证业务前后一致性。
1、RocketMQ事务消息
RocketMQ在4.3版中开始支持分布式事务消息，采用2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示：
上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。
1.1 发送及提交
(1)发送消息(half消息，即发送但不被消费);
(2)服务端响应消息写入结果;
(3)根据发送结果执行本地事务,如果写入失败，此时half消息对业务不可见，本地逻辑不执行;
(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
1.1 补偿流程
(1)对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”;
(2)Producer收到回查消息，检查回查消息对应的本地事务的状态;
(3)根据本地事务状态，重新Commit或者Rollback;
其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。
1.3 设计原理
在RocketMQ事务消息的主要流程中，一阶段的消息如何对用户不可见。其中，事务消息相对普通消息最大的特点就是一阶段发送的消息对用户是不可见的。那么，如何做到写入消息但是对用户不可见呢？RocketMQ事务消息的做法是：如果消息是half消息，将备份原消息的主题与消息消费队列，然后改变主题为RMQ_SYS_TRANS_HALF_TOPIC。由于消费组未订阅该主题，故消费端无法消费half类型的消息，然后RocketMQ会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息进行消费，根据生产者组获取一个服务提供者发送回查事务状态请求，根据事务状态来决定是提交或回滚消息。
2、最终一致性
基于上述RocketMQ事务消息可靠性的特点，即可以实现某类业务下事务的最终一致性。消息发送一致性是指产生消息的业务动作与消息发送一致，也就是说如果业务操作成功，那么由这个业务操作所产生的异步消息一定要发送出去，否则就业务失败回滚，消息也会丢弃。
流程基本如下：
- 发送half事务消息，无法被消费；
- 本地业务代码逻辑处理完成；
- 发送确认消息，标识该消息可以消费；
- 如果消息生产方异常，取消整体动作；
该流程主要针对消息生产方，在实际开发中，消息的消费方也一样很难处理，要保证最终一致性，必然会面对一个问题，消费方异常，消息不断的重试，可能存在部分业务处理成功，部分业务处理失败的情况，这时候就要解决服务接口的幂等性问题。
九、幂等接口
1、幂等简介
编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。就是说，一次和多次请求某一个资源会产生同样的作用影响。
在复杂的异步流程中，尤其注意失败重试问题，通常支付流程中，每次接口被请求，对每一步数据更新的操作，都会前置一步状态查询的流程，用来判断下一步的数据更新是否该执行。
2、幂等接口
在系统服务接口请求中，任何明确的接口响应，例如失败或成功，这样业务流程都好处理，但是例如支付场景如果请求超时，如何判断服务的结果状态：客户端请求超时，本地服务超时，请求支付超时，支付回调超时，客户端响应超时等，或者基于MQ的不断重试机制，在部分业务异常状态下，始终没有返回成功，则消息会一直重试。
这就需要设计流程化的状态管理，尤其在消息重试机制下，很少会再次对重试的业务接口使用重度的事务控制，有些业务被执行完毕，只需要判断一个状态，下次消息重试跳过即可，只需要把未处理的业务补偿处理即可，在重试机制下，在部分业务没有全部执行成功之前，消息会一直重试，直到最终全部完成。
十、参考源码
应用仓库：
https://gitee.com/cicadasmile/butte-flyer-parent
组件封装：
https://gitee.com/cicadasmile/butte-frame-parent
复制代码