详解三种主流分布式事务方案的优劣(2)

发布时间：2019-11-04 13:47 所属栏目：21 来源：BlueMiaomiao

导读：1)实现：一个完整的业务活动由一个主业务服务于若干的从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供TCC型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动的操作，并在业务

1)实现：一个完整的业务活动由一个主业务服务于若干的从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供TCC型业务操作。业务活动管理器控制业务活动的一致性，它登记业务活动的操作，并在业务活动提交时确认所有的TCC型操作的Confirm操作，在业务活动取消时调用所有TCC型操作的Cancel操作。

2)成本：实现TCC操作的成本较高，业务活动结束的时候Confirm和Cancel操作的执行成本。业务活动的日志成本。

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

4)特点：不与具体的服务框架耦合，位于业务服务层，而不是资源层，可以灵活的选择业务资源的锁定粒度。TCC里对每个服务资源操作的是本地事务，数据被锁住的时间短，可扩展性好，可以说是为独立部署的SOA服务而设计的。

最大努力通知型

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

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

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

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

5)特点：业务活动的主动方在完成业务处理之后，向业务活动的被动方发送通知消息。主动方可以设置时间阶梯通知规则，在通知失败后按规则重复通知，知道通知N次后不再通知。主动方提供校对查询接口给被动方按需校对查询，用户恢复丢失的业务消息。

适用范围：银行通知，商户通知。

三、基于可靠消息的最终一致性方案

消息发送一致性

消息中间件在分布式系统中的核心作用就是异步通讯、应用解耦和并发缓冲(也叫作流量削峰)。在分布式环境下，需要通过网络进行通讯，就引入了数据传输的不确定性，也就是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方式的分布式事务，就会带来很多局限性。

要求业务操作的资源必须支持XA协议，但是并不是所有的资源都支持XA协议。

两阶段提交协议的成本。

持久化成本等DTP模型的局限性，例如：全局锁定、成本高、性能低。

使用XA协议违背了柔性事务的初衷。

保证消息一致的变通做法