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

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协议违背了柔性事务的初衷。

保证消息一致的变通做法

1)发送消息：主动方现将应用把消息发给消息中间件，消息状态标记为“待确认”状态。

2)消息中间件收到消息后，把消息持久化到消息存储中，但是并不影响被动方投递消息。

3)消息中间件返回消息持久化结果，主动方根据返回的结果进行判断如何进行业务操作处理：

• 失败：放弃执行业务操作处理，结束，必要时向上层返回处理结果;
• 成功：执行业务操作处理。

4)业务操作完成后，把业务操作结果返回给消息中间件。消息中间件收到业务操作结构后，根据业务结果进行处理：

• 失败：删除消息存储中的消息，结束;
• 成功：更新消息存储中的消息状态为“待发送”，然后执行消息投递。

前面的正向流程都成功之后，向被动方应用投递消息。但是在上面的处理流程中，任何一个环节都有可能出现问题。

常规MQ消息处理流程和特点

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

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

对于未确认的消息，采用按规则重新投递的方式进行处理。对于以上流程，消息重复发送会导致业务处理接口出现重复调用的问题。

消息消费过程中消息重复发送的主要原因就是消费者成功接收处理完消息后，消息中间件没有及时更新投递状态导致的。如果允许消息重复发送，那么消费方应该实现业务接口的幂等性设计。

本地消息服务方案

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!