分布式事务中的三种解决方案详解

时间  2019-11-07
标签 分布式 事务 三种 解决 方案 详解 栏目 系统架构 繁體版
原文   原文链接

[TOC]java

1、分布式事务前奏

  • 事务：事务是由一组操做构成的可靠的独立的工做单元，事务具有ACID的特性，即原子性、一致性、隔离性和持久性。
  • 本地事务：当事务由资源管理器本地管理时被称做本地事务。本地事务的优势就是支持严格的ACID特性，高效，可靠，状态能够只在资源管理器中维护，并且应用编程模型简单。可是本地事务不具有分布式事务的处理能力，隔离的最小单位受限于资源管理器。
  • 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。
  • TX协议：应用或者应用服务器与事务管理器的接口。
  • XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间做为通讯桥梁。之因此须要XA是由于在分布式系统中从理论上讲两台机器是没法达到一致性状态的，所以引入一个单点进行协调。由全局事务管理器管理和协调的事务能够跨越多个资源和进程。全局事务管理器通常使用XA二阶段协议与数据库进行交互。
  • AP：应用程序，能够理解为使用DTP（Data Tools Platform）的程序。
  • RM：资源管理器，这里能够是一个DBMS或者消息服务器管理系统，应用程序经过资源管理器对资源进行控制，资源必须实现XA定义的接口。资源管理器负责控制和管理实际的资源。
  • TM：事务管理器，负责协调和管理事务，提供给AP编程接口以及管理资源管理器。事务管理器控制着全局事务，管理事务的生命周期，而且协调资源。
  • 两阶段提交协议：XA用于在全局事务中协调多个资源的机制。TM和RM之间采起两阶段提交的方案来解决一致性问题。两节点提交须要一个协调者（TM）来掌控全部参与者（RM）节点的操做结果而且指引这些节点是否须要最终提交。两阶段提交的局限在于协议成本，准备阶段的持久成本，全局事务状态的持久成本，潜在故障点多带来的脆弱性，准备后，提交前的故障引起一系列隔离与恢复难题。
  • BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是容许短期内不一样步，E表示最终一致性，数据最终是一致的，可是实时是不一致的。原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的须要，只有下降一致性和隔离性的要求。
  • CAP定理：对于共享数据系统，最多只能同时拥有CAP其中的两个，任意两个都有其适应的场景，真是的业务系统中一般是ACID与CAP的混合体。分布式系统中最重要的是知足业务需求，而不是追求高度抽象，绝对的系统特性。C表示一致性，也就是全部用户看到的数据是同样的。A表示可用性，是指总能找到一个可用的数据副本。P表示分区容错性，可以容忍网络中断等故障。
  • 柔性事务中的服务模式：
    1. 可查询操做：服务操做具备全局惟一的标识，操做惟一的肯定的时间。
    2. 幂等操做：重复调用屡次产生的业务结果与调用一次产生的结果相同。一是经过业务操做实现幂等性，二是系统缓存全部请求与处理的结果，最后是检测到重复请求以后，自动返回以前的处理结果。
    3. TCC操做：Try阶段，尝试执行业务，完成全部业务的检查，实现一致性；预留必须的业务资源，实现准隔离性。Confirm阶段：真正的去执行业务，不作任何检查，仅适用Try阶段预留的业务资源，Confirm操做还要知足幂等性。Cancel阶段：取消执行业务，释放Try阶段预留的业务资源，Cancel操做要知足幂等性。TCC与2PC(两阶段提交)协议的区别：TCC位于业务服务层而不是资源层，TCC没有单独准备阶段，Try操做兼备资源操做与准备的能力，TCC中Try操做能够灵活的选择业务资源，锁定粒度。TCC的开发成本比2PC高。实际上TCC也属于两阶段操做，可是TCC不等同于2PC操做。
    4. 可补偿操做：Do阶段：真正的执行业务处理，业务处理结果外部可见。Compensate阶段：抵消或者部分撤销正向业务操做的业务结果，补偿操做知足幂等性。约束：补偿操做在业务上可行，因为业务执行结果未隔离或者补偿不完整带来的风险与成本可控。实际上，TCC的Confirm和Cancel操做能够看作是补偿操做。

2、柔性事务解决方案架构

在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。柔性事务有两个特性：基本可用和柔性状态。所谓基本可用是指分布式系统出现故障的时候容许损失一部分的可用性。柔性状态是指容许系统存在中间状态，这个中间状态不会影响系统总体的可用性，好比数据库读写分离的主从同步延迟等。柔性事务的一致性指的是最终一致性。数据库

（一）、基于可靠消息的最终一致性方案概述

分布式事务中的三种解决方案详解

  • 实现：业务处理服务在业务事务提交以前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交以后，向实时消息服务确认发送。只有在获得确认发送指令后，实时消息服务才会真正发送。
  • 消息：业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息发送状态确认系统按期找到未确认发送或者回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或者消息内容确认该消息是否有效。被动方的处理结果不会影响主动方的处理结果，被动方的消息处理操做是幂等操做。
  • 成本：可靠的消息系统建设成本，一次消息发送须要两次请求，业务处理服务须要实现消息状态回查接口。
  • 优势：消息数据独立存储，独立伸缩，下降业务系统和消息系统之间的耦合。对最终一致性时间敏感度较高，下降业务被动方的实现成本。兼容全部实现JMS标准的MQ中间件，确保业务数据可靠的前提下，实现业务的最终一致性，理想状态下是准实时的一致性。

（二）、TCC事务补偿型方案

分布式事务中的三种解决方案详解

  • 实现：一个完整的业务活动由一个主业务服务于若干的从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供TCC型业务操做。业务活动管理器控制业务活动的一致性，它登记业务活动的操做，并在业务活动提交时确认全部的TCC型操做的Confirm操做，在业务活动取消时调用全部TCC型操做的Cancel操做。
  • 成本：实现TCC操做的成本较高，业务活动结束的时候Confirm和Cancel操做的执行成本。业务活动的日志成本。
  • 使用范围：强隔离性，严格一致性要求的业务活动。适用于执行时间较短的业务，好比处理帐户或者收费等等。
  • 特色：不与具体的服务框架耦合，位于业务服务层，而不是资源层，能够灵活的选择业务资源的锁定粒度。TCC里对每一个服务资源操做的是本地事务，数据被锁住的时间短，可扩展性好，能够说是为独立部署的SOA服务而设计的。

（三）、最大努力通知型

分布式事务中的三种解决方案详解

  • 实现：业务活动的主动方在完成处理以后向业务活动的被动方发送消息，容许消息丢失。业务活动的被动方根据定时策略，向业务活动的主动方查询，恢复丢失的业务消息。
  • 约束：被动方的处理结果不影响主动方的处理结果。
  • 成本：业务查询与校对系统的建设成本。
  • 使用范围：对业务最终一致性的时间敏感度低。跨企业的业务活动。
  • 特色：业务活动的主动方在完成业务处理以后，向业务活动的被动方发送通知消息。主动方能够设置时间阶梯通知规则，在通知失败后按规则重复通知，知道通知N次后再也不通知。主动方提供校对查询接口给被动方按需校对查询，用户恢复丢失的业务消息。
  • 适用范围：银行通知，商户通知。

3、基于可靠消息的最终一致性方案详解

（一）、消息发送一致性

消息中间件在分布式系统中的核心做用就是异步通信、应用解耦和并发缓冲（也叫做流量削峰）。在分布式环境下，须要经过网络进行通信，就引入了数据传输的不肯定性，也就是CAP理论中的分区容错性。编程

分布式事务中的三种解决方案详解

消息发送一致性是指产生消息的业务动做与消息发送一致，也就是说若是业务操做成功，那么由这个业务操做所产生的消息必定要发送出去，不然就丢失。缓存

处理方式一服务器

public void completeOrderService() {
    // 处理订单
    order.process();

    // 发送会计原始凭证消息
    pipe.sendAccountingVouchetMessage();
}

在上面的状况中，若是业务操做成功，执行的消息发送以前应用发生故障，消息发送不出去，致使消息丢失，将会产生订单系统与会计系统的数据不一致。若是消息系统或者网络异常，也会致使消息发送不出去，也会形成数据不一致。网络

处理方式二架构

public void completeOrderService() {
    // 发送会计原始凭证消息
    pipe.sendAccountingVouchetMessage();

    // 处理订单
    order.process();
}

若是将上面的两个操做调换一下顺序，这种状况就会更加不可控了，消息发出去了业务订单可能会失败，会形成订单系统与业务系统的数据不一致。那么JMS标准中的XA协议是否能够保障发送的一致性？并发

  • JMS协议标准的API中，有不少以XA开头的接口，其实就是前面讲到的支持XA协议（基于两阶段提交协议）的全局事务型接口。框架

    XAConnection.class
XAConnectionFactory.class
XAQueueConnection.class
XAQueueConnectionFactory.class
XASession.class
XATopicConnection.class
XATopicConnectionFactory.class
XATopicSession.class
  • JMS中的XA系列的接口能够提供分布式事务的支持。可是引用XA方式的分布式事务，就会带来不少局限性。
    1. 要求业务操做的资源必须支持XA协议，可是并非全部的资源都支持XA协议。
    2. 两阶段提交协议的成本。
    3. 持久化成本等DTP模型的局限性，例如：全局锁定、成本高、性能低。
    4. 使用XA协议违背了柔性事务的初衷。

（二）、保证消息一致的变通作法

分布式事务中的三种解决方案详解

  1. 发送消息：主动方现将应用把消息发给消息中间件，消息状态标记为“待确认”状态。
  2. 消息中间件收到消息后，把消息持久化到消息存储中，可是并不影响被动方投递消息。
  3. 消息中间件返回消息持久化结果，主动方根据返回的结果进行判断如何进行业务操做处理：
    1. 失败：放弃执行业务操做处理，结束，必要时向上层返回处理结果。
    2. 成功：执行业务操做处理。
  4. 业务操做完成后，把业务操做结果返回给消息中间件。
  5. 消息中间件收到业务操做结构后，根据业务结果进行处理：
    1. 失败：删除消息存储中的消息，结束。
    2. 成功：更新消息存储中的消息状态为“待发送”，而后执行消息投递。
  6. 前面的正向流程都成功以后，向被动方应用投递消息。

可是在上面的处理流程中，任何一个环节都有可能出现问题。异步

（三）、常规MQ消息处理流程和特色

分布式事务中的三种解决方案详解

  • 常规的MQ队列处理流程没法实现消息的一致性。
  • 投递消息的本质就是消息消费，能够细化。

（四）、消息重复发送问题和业务接口幂等性设计

分布式事务中的三种解决方案详解

对于未确认的消息，采用按规则从新投递的方式进行处理。对于以上流程，消息重复发送会致使业务处理接口出现重复调用的问题。消息消费过程当中消息重复发送的主要缘由就是消费者成功接收处理完消息后，消息中间件没有及时更新投递状态致使的。若是容许消息重复发送，那么消费方应该实现业务接口的幂等性设计。

（五）、本地消息服务方案

分布式事务中的三种解决方案详解

  • 实现思路：
    1. 主动方应用系统经过业务操做完成业务数据的操做，在准备发送消息的时候将消息存储在主动方应用系统一份，另外一份发送到实时消息服务
    2. 被动方应用系统监听实时消息系统中的消息，当被动方完成消息处理后经过调用主动方接口完成消息确认
    3. 主动方接收到消息确认之后删除消息数据。
    4. 经过消息查询服务查询到消息被接收以后再规定的时间内没有返回ACK确认消息就经过消息恢复系统从新发送消息。
  • 优势：
    1. 消息的时效性比较高
    2. 从应用设计的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。
    3. 方案轻量级，容易实现。
  • 缺点：
    1. 与具体的业务场景绑定，耦合性强，不能够共用。
    2. 消息数据与业务数据同步，占用业务系统资源。
    3. 业务系统在使用关系型数据库的状况下消息服务性能会受到关系型数据库的并发性能限制。

（六）、独立消息服务方案

分布式事务中的三种解决方案详解

  • 实现思路：
    1. 预发送消息：主动方应用系统预发送消息，由消息服务子系统存储消息，若是存储失败，那么也就没法进行业务操做。若是返回存储成功，而后执行业务操做。
    2. 执行业务操做：执行业务操做若是成功的时候，将业务操做执行成功的状态发送到消息服务子系统。消息服务子系统修改消息的标识为“可发送”状态。
    3. 发送消息到实时消息服务：当消息的状态发生改变的时候，马上将消息发送到实时消息服务中。接下来，消息将会被消息业务的消费端监听到，而后被消费。
    4. 消息状态子系统：至关于定时任务系统，在消息服务子系统中定时查找确认超时的消息，在主动方应用系统中也去定时查找没有处理成功的任务，进行相应的处理。
    5. 消息消费：当消息被消费的时候，向实时消息服务发送ACK，而后实时消息服务删除消息。同时调用消息服务子系统修改消息为“被消费”状态。
    6. 消息恢复子系统：当消费方返回消息的时候，因为网络中断等其余缘由致使消息没有及时确认，那么须要消息恢复子系统定时查找出在消息服务子系统中没有确认的消息。将没有被确认的消息放到实时消息服务中，进行重作，由于被动方应用系统的接口是幂等的。
  • 优势：
    1. 消息服务独立部署，独立维护，独立伸缩。
    2. 消息存储能够按需选择不一样的数据库来集成实现。
    3. 消息服务能够被相同的的使用场景使用，下降重复建设服务的成本。
    4. 从分布式服务应用设计开发角度实现了消息数据的可靠性，消息数据的可靠性不依赖于MQ中间件，弱化了对MQ中间件特性的依赖。
    5. 下降了业务系统与消息系统之间的耦合，有利于系统的扩展维护。
  • 缺点：
    1. 一次消息发送须要两次请求。
    2. 主动方应用系统须要实现业务操做状态的校验与查询接口。

（七）、消息服务子系统的设计实现

示例消息数据表：

名称 数据类型 容许空 默认值 属性 释义
uuid varchar(50) No — unique UUID
version int(11) No 0 — 版本号
editer varchar(100) Yes NULL — 修改者
creater varchar(100) Yes NULL — 建立者
edit_time datetime Yes 0000-00-00 00:00:00 — 最后修改时间
create_time datetime No 0000-00-00 00:00:00 — 建立时间
msg_id varchar(50) No — — 消息ID
msg_body longtext No — — 消息内容
msg_date_type varchar(50) Yes — — 消息数据类型
consumer_queue varchar(100) No — — 消费队列
send_times int(6) No 0 — 消息重发次数
is_dead varchar(20) No — — 是否死亡
status varchar(20) No — — 状态
remark varchar(200) Yes — — 备注
field0 varchar(200) Yes — — 扩展字段0
field1 varchar(200) Yes — — 扩展字段1
field2 varchar(200) Yes — — 扩展字段2
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程