可靠消息服务实现具体方案

分布式事务往往是服务化的痛点，很多场景通过业务避免了分布式事务，但是还是存在一些场景必须依赖分布式事务，下面来讲讲如何处理分布式事务

成都创新互联长期为上千余家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为新洲企业提供专业的网站建设、成都网站制作，新洲网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。

一 常用解决方案

分布式事物解决方式有很多，网上博客也有一大堆 总结一般有如下两种

1 刚性分布式事务，两阶段提交 强一致性

2 柔性分布式事务 最大努力提交 ,tcc,可靠消息服务

首先解决分布式事务前提保障：接口必须幂等性，防止消息重复发送对业务影响

二 可靠消息系统设计（这个感觉不错比较简单，就拿来分享下）

如上图

开始执行 比如：try{if(prepare()) { //预发送阶段doService(); //执行业务逻辑updateMsgStatus();//更新消息为确认状态}}

1 预发送消息，try阶段，如果预发送消息失败了，业务还未执行，所以 系统A，B还是一致性的 不需要处理

这一点容易理解

2 预发送消息成功了，开始执行业务逻辑。执行成功 更新预发送消息转态为确认发送。如果 此时 业务逻辑执行失败了，那预发送消息就不会跟新状态，此时消息确认系统就开启工作，到业务系统1上回查此消息状态，此时发现业务执行失败了，就更新预发送状态至失败状态。

3 如果此时 业务执行成功了消息也被更新成确认发送了 那就ok 完美。如果消息更新失败，还是由消息确认系统回查转态 更新此消息被删除状态还是确认发送状态。

4 消息者开始消费

1> 比如消费失败了，此时产生不一致， 消息恢复系统检测消息状态，重新发送消息

2>如果执行业务失败了，此消息也就不会被确认了，还是由消息恢复系统检测消息状态，重新发送消息

3>如果ask失败了，还是以上逻辑重新发送上诉重新发送当然有次数限制，不能一直发送，超过最大次数就要进入死信队列，等待人工干预了

4> ask成功，消息也就成功消费了，完美，解决了消息可靠服务

三 努力提交

这个比较简单 ，将失败的消息重复提交，实时性比较弱的一些场景，确保消息推送成功。

比如交易完成推送第三方消息。 此时可以使用努力提交

分享文章：可靠消息服务实现具体方案
链接地址：http://www.shufengxianlan.com/qtweb/news9/293509.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联