分布式事务的思路

在一些项目中，有时会遇到关于分布式事务的场景，关于分布式事务它有很多的问题与思路。
比如电商平台中关于商品的支付业务中：
1.用户在电商平台选择商品，下订单选择支付平台。
2.在支付平台请求支付平台，选择支付方式，进行支付。
3.请求银行，创建支付交易并扣款。
4.银行会返回扣款结果，成功或是失败。
5.支付平台向电商平台返回支付结果。
6.电商平台返回结果给用户。
在上面的整个业务流转过程中，只要扣款成功，那么后续的操作必然不能是同步的，不管是异步执行还是同步执行，必须全部成功或者失败，但是在这个业务场景中，既然支付成功，那么要求后续的模块系统必须全部支付成功，这就是分布式事务问题，而再用常规的事务解决方案是不可行的。

对于分布式事务的解决，每个公司的处理方式是不一样的，市面上也有很多的产品可以解决，但是总归有这样或者那样的问题。我们可以尝试去了解大多数分布式事务的解决方案，来了解它的思路与解决。
很多大型的互联网公司都是自主研发了分布式事务框架或者中间件，支付宝使用的是XTS,去哪儿网QMQ，我们可以把常用的分布式事务解决方案研究一遍，来设计一个更加轻量级的，解决大部分设计分布式事务的场景。

我们知道事务是一组操作构成的可靠的，独立的工作单元。具有ACID的特性，并具有高度并发，资源分布，大时间跨度的难度特性。

本地事务
本地事务由资源管理器本地管理，它支持严格的ACID属性，可靠高效，应用编程模型简单，但不具备分布事务处理能力，且隔离的最小单位由资源管理器决定。在单个数据库的本地并且限制在单个进程内的事务，不涉及多个数据来源。

全局事务
它是标准的分布式事务，它的事务由全局事务管理器进行全局管理，管理全局事务的状态与参与的资源，协同资源的一致提交或回滚。全局事务遵循XA协议，XA引入分布式系统，作为一个单点对事务管理器与资源管理器进行协调，XA是X/Open组织提出的分布式事务的规范，主流的关系型数据库，如MySQL，Oracle，都实现了XA协议。
在软件架构中有一句话，当解决不了问题的时候，引入第三方就可以了

两阶段提交
两阶段提交需要一个协调者去掌控所有参与者节点的操作结果并指引这些节点是否需要最终提交，它在准备后，事务结果已经持久，仍可提交与回滚，准备时一致性检查必须OK，但具有潜在故障点带来的脆弱性，准备后，提交前的故障引发一系列隔离与恢复难题。

终上所述，标准 分布式服务解决的方案有严格的ACID，但是它的效率低下，对于微服务架构下已经不适用了，全局事务下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（2PC）与资源层（如数据库）进行交互。使用全局事务，数据被Lock的时间跨越整个事务，直到全局事务结束，2PC是反可伸缩模式，在数据处理过程中，参与者需要一直持有资源直到整个分布式事务的结束。这样，当业务规模越来越大的情况下，2PC的局限性就越来越明显，系统可伸缩性会变得很差。与本地事务相比，XA协议的系统开销相当大，因而应当慎重考虑是否确实需要分布式事务。而且只有支持XA协议的资源才能参与分布式事务。

BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。它的原子性与持久性必须根本保障，为了可用性，性能与降级服务的需要，降低一致性与隔离性的要求。

CPA定理
对于共享数据系统，最多只能同时拥有CPA其中的两个，没法三者兼顾。其任两者的组合都有其适用场景，比如zk满足其一致性与分区容错性，eureka满足其可用性与分区容错性。所以分布式系统中，最重要的是满足业务需求，而不是追求对象和绝对的系统特性。

柔性事务解决方案
1.可靠消息最终一致性（异步确保型）

实现：
业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送

消息：
业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或者回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或者消息内容确定该消息是否有效

约束：
被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作

成本：
可靠消息服务建设成本
一次消息发送需要两次确认，业务处理服务需要实现消息状态回查接口

优点，适用范围：
消息数据独立存储，独立伸缩，降低业务系统与消息系统间的耦合
对最终一致性时间敏感度较高，降低业务被动方实现成本

用到的服务模式：
可查询操作，幂等操作

方案特点：
兼容所有实现JMS标准中间件，
确保业务数据可靠性前提下，实现业务数据的最终一致性（理想状态下基本是准实时一致的）

行业应用：
支付宝，ebay，去哪儿，携程…

2.TCC（两阶段，补偿性）

实现：
一个完成的业务活动由一个主业务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务提供TCC型业务操作
业务活动管理器控制业务活动的一致性，它等级业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务员活动取消时调用所有TCC型操作的cancel操作

成本：
实现TCC操作的成本
业务活动结束时confirm或cancel操作执行成本
业务活动的日志成本

适用范围：
强隔离性，严格一致性要求的业务活动
适用于执行时间较短的业务，（比如处理账户，收费等业务）

用到的服务模式：
TCC操作，幂等操作，可补偿操作，可查询操作

方案特点：
不与具体的服务框架耦合（在RPC架构中通用）
位于业务服务层，而非资源层
可以灵活选择业务资源的锁定粒度
TCC里对每个服务资源的操作都是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）

行业应用：
支付宝XTS(蚂蚁金融云的分布式事务服务DTS)

3.最大努力通知（定期校对）

实现：
业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失
业务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息

约束：
被动方的处理结果不影响主动方的处理结果

成本：
业务查询与校对系统的建设成本

适用范围：
对业务最终一致性的时间敏感度低
跨企业的业务活动

用到的服务模式：
可查询操作

方案特点：
业务活动的主动方在完成业务处理后，向业务活动被动范发送通知消息（允许消息丢失）
主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知
主动方提供小队校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息

行业应用案例：
银行通知 商户通知等（各大交易业务平台间的商户通知：多次通知，查询校对，对账文件等）

消息发送的一致性

• 1.主动方应用先把消息发给消息中间件，消息状态标记为“待确认”
• 2.消息中间件受到消息后，把消息持久化到消息存储中，但不向被动方应用投递消息
• 消息中间件返回持久化结果（成功/失败）,主动方应用根据返回结果进行判断如何进行业务操作处理
  • 失败：放弃业务操作处理，结束（必要时向上层返回失败结果）
  • 成功：执行业务操作逻辑
• 4.业务操作完成后，把业务操作结果（success/fail）发送给消息中间件
• 5.消息中间价收到业务操作结果后，根据业务结果进行处理
  • 失败：删除消息存储中的消息，结束；
  • 成功：更新消息存储中的消息状态为“待发送（可发送）”
• 6.被动方应用监听并接收“待发送”状态的消息，执行业务处理
• 7.业务处理完成后，向消息中间件发送ACK确认，确认消息已经收到，（消息中间件将从队列中删除该消息）

可靠消息最终一致性方案
设计分析维度

• 消息发送一致性的正向流程
• 消息发送一致性的异常处理流程
• 消息投递（消费）的正向流程
• 消息投递（消费）的异常处理流程

优点

• 消息时效性较高
• 从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖
• 方案轻量，容易实现

弊端

• 与具体的业务场景绑定，耦合性强，不可共用
• 消息数据与业务数据同库，占用业务系统资源
• 业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限

在我们的方案中，我们依赖了两个比较重要的中间服务层面，一个是实时消息服务，另一个是可靠的消息服务
这里的消息服务为了做的更加通用，不与任何消息中间件耦合，兼容基本上市面上的JMS或者AMQP协议的中间件，用来存储和保证消息的可靠性
当然不同的消息产品在保证自己的可靠性上都有不同的做法，这里要做的就是屏蔽这些差异性。