标签：可靠消息 XA 业务 发送 消息 消息中间件 一致性 copy 分布式

消息发送一致性（可靠消息的前提保障）

一、消息中间件的应用场景

消息中间件在分布式系统中的主要作用：异步通讯、解耦、并发缓冲
如图：通过引入消息中间件来解耦应用间（服务间）的直接调用，同时也会起到异步通讯和缓冲并发的作用
二、消息发送和投递的不可靠性

分布式部署环境下，需要通过网络进行通讯，就引入了数据传输的不确定性也就是CAP理论中的P（分区容错性的问题）

三、消息发送一致性
消息发送一致性：是指产生消息的业务动作与消息发送的一致。

（也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息） 

四、消息发送一致性如何保障？
1. 处理方式1
/** 支付订单处理 **/
public void completeOrder() {
// 订单处理（业务操作）
orderBiz.process();
// 发送会记原始凭证消息（发送消息）
sendAccountingVoucherMsg ();
}
如果业务操作成功，执行消息发送前应用故障，消息发不出去，导致消息丢失（订单系统与会计系统的数据不一致）
如果业务操作成功，应用正常，但消息系统故障或网络故障，也会导致消息发不出去（订单系统与会计系统的数据不一致）
2. 处理方式2
/** 支付订单处理 **/
public void completeOrder() {
// 发送会记原始凭证消息（发送消息）
sendAccountingVoucherMsg ();
// 订单处理（业务操作）
orderBiz.process();
}
这种情况下，更不可控，消息发出去了，但业务可能会失败（订单系统与会计系统的数据不一致）
前面两种方式，都不能保证业务数据的一致性。

五、JMS标准中的XA协议方式是否可以保障发送一致性？
JMS协议标准的API中，有很多以XA开头的接口，其实就是前面课程讲到的支持XA协议（基于两阶段提交协议）的 全局事务型接口。JMS中的XA系列接口，可以提供分布式事务支持。 但引用了XA方式的分布式事务，又会带来很多的局限：

要求业务操作的资源必须支持XA协议（并不是所有资源都支持XA）
两阶段提交协议的成本
持久化成本等DTP模型的局限性（全局锁定，成本高，性能低）
引入XA，违背了柔性事务的初衷

六、消息发送一致性：变通的做法

主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；
消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；
消息中间件返回消息持久化结果（成功/失败），主动方应用根据返回结果进行判断如何进行业务操作处理：
失败：放弃业务操作处理，结束（必要时向上层返回失败结果）；
成功：执行业务操作处理；
业务操作完成后，把业务操作结果（成功/失败）发送给消息中间件；
消息中间件收到业务操作结果后，根据业务结果进行处理；
失败：删除消息存储中的消息，结束；
成功：更新消息存储中的消息状态为“待发送（可发送）”，紧接着执行消息投递；
前面的正向流程都成功后，向被动方应用投递消息；
七、待解决问题
消息发送一致性方案的正向流程是可行的，但异常流程怎么处理呢？ 消息发送到消息中间件中能得到保障了，但消息的准确消费（投递）又如何保障呢？ 有没有支持这种发送一致性流程的现成消息中间件？

八、待续
分布式事务五
————————————————
版权声明：本文为CSDN博主「chenshiying007」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_27384769/article/details/79305402

标签：可靠消息,XA,业务,发送,消息,消息中间件,一致性,copy,分布式
来源： https://www.cnblogs.com/hanease/p/14466200.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。