本文主要是介绍java 可靠消息服务_可靠消息最终一致（异步确保型），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
一致性设计在分布式系统中是一个重要问题。如果一个系统同时使用多个子数据系统来存储与读取数据，就必须设计满足功能需求的一致性定义。如果系统对不同数据子系统进行操作的结果不一致，不但可能会使用户困惑，更可能引发更严重的数据问题或系统错误。一致性有多种级别，适用于不同的业务场景。对于金融等对数据一致性要求较高的行业，传统的事务可以提供较高的一致性保证。对于分布式系统等对性能(performance)和可用性(availability)要求较高的场景，牺牲一定的强一致性来换取更好的用户体验也可接受。
在之前写过一次关于TCC事务的笔记，也了解了分布式事务产生的原因，以及部分解决方案，这次一起跟大家总结下最终一致性方案设计思路的相关内容；
场景
消息发送一致性的概念：是指产生消息的业务动作与消息发送的一致。
也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息
最终一致性可以使用在类似如下功能场景当中：
对应支付系统会计异步记账业务
普通的积分账户增加积分的服务
也就是说：采用最终一致性的数据系统通常不要求数据操作失败时执行回滚(rollback)。用户或系统日志将得知操作失败，但在另一次成功的操作之前，数据的不一致问题并不会被自动修复。
ps:肯定会有小伙伴有疑问，我执行程序的时候代码报错了导致最终一致性的方案不成功怎么办？？？小朋友你是不是有很多？？？
如果是代码报错，本身说明了你的业务代码有问题，而不是最终一致性方案的锅~~。
实现流程
最终一致性可以借助消息中间件，消息队列等工具实现，需要根据自己的业务去定制不同的技术方案；
咱们要介绍的是基于RabbitMq实现的一个可靠消息服务系统来完成事务的执行，具体流程如下图：
主动方应用先把消息发给消息中间件，消息状态标记为“待确认”；
消息中间件收到消息后，把消息持久化到消息存储中，但并不向被动方应用投递消息；
消息中间件返回消息持久化结果(成功/失败)，主动方应用根据返回结果进行判断如何进行业务操作处理：
失败：放弃业务操作处理，结束(必要时向上层返回失败结果)；
成功：执行业务操作处理；
业务操作完成后，把业务操作结果(成功/失败)发送给消息中间件；
消息中间件收到业务操作结果后，根据业务结果进行处理；
失败：删除消息存储中的消息，结束；
成功：更新消息存储中的消息状态为“待发送(可发送)”，紧接着执行消息投递；
被动方应用监听并接收“待发送”状态的消息，执行业务处理；
业务处理完成后，向消息中间件发送ACK，确认消息已经收到(消息)中间件将从队列中删除该消息)
除了以上几个流程，消息系统还应该提供ackMsg消息确认服务、消息状态查询服务。
异常的处理流程
主动方角度
从中间件的角度
异常情况的总结处理
方案落地
消息系统组成
消息服务子系统：
是最重要的一个子系统，它接收并存储预发送的消息，并提供进一步的确认功能。一般需要实现以下接口服务。
存储预发送消息(主动方应用系统)
确认并发送消息(主动方应用系统)
查询状态确认超时的消息(消息状态确认子系统)
确认消息已被成功消费(被动方应用系统)
查询消费确认超时的消息(消息恢复子系统)
消息管理子系统：
提供一个可视化的管理界面，对可靠消息服务系统中的数据，进行查询和管理。比如可查看已死亡的消息，可通过界面手工重发等
消息状态确认子系统：
提供对异常情况的处理。当消息服务子系统收到并保存预发送消息，但因异常情况，没有收到确认发送消息时，这种消息不可能一直留存在数据库中。这种情况的数据，就需要消息状态确认子系统定期捞取这些待确认超时的数据，去调用主动方应用系统中的业务查询接口进行核对确认。根据核对结果决定是发送消息还是删除数据。
消息恢复子系统：
如果消息数据已经接收到业务确认，这种经过业务确认的消息，就一定要发送到MQ，并被消费方成功消费，绝不能丢。消息恢复子系统定期捞取那些状态是“发送中”，而没有被消费确认的超时消息，进行重新发送。
实时消息服务子系统(MQ)：
消费方监听程序，接收MQ消息，成功处理后调用消息服务子系统的接口，确认消息已被成功消费，可以删除。
整体流程
用户下单，主动方应用预发送消息给消息服务子系统。
消息服务子系统存储预发送的消息。
返回存储预发送消息的结果。
如果第3步返回的结果是成功的，则执行业务操作，否则不执行。
业务操作成功后，调用消息服务子系统进行确认发送消息。
将消息服务库中存储的预发送消息发送，并更新该消息的状态为已发送(但不是已被消费)。
消息中间件发送消息到消费端应用。
消费端应用调用被动方应用服务。
被动方应用返回结果给消费端应用。
消费端应用向消息中间件ack此条消息，并向消息服务子系统进行确认成功消费消息，
让消息服务子系统删除该条消息或者将状态置为已成功消费。
消息状态子系统定时去查一下消息数据，看看有没有是已发送状态的超时消息，就是一直没有变成已成功消费的那种消息，主动方应用系统应该提供查询接口，针对某条消息查询该条消息对应的业务数据是否为处理成功
如果业务数据是处理成功的状态，那么就再次调用确认并发送消息，即进入第6步。
如果业务数据是处理失败的，那么就调用消息服务子系统进行删除该条消息数据。
谢谢观赏
本文是学习过程中的笔记整理，如果有不对的地方请大家联系我，及时纠正，避免误导童鞋们，谢谢各位童鞋的耐心观看，希望本文会帮助到您~后期计划在Hyperf中写一个demo，感兴趣的可以留意我的GitHub。
关于找一找教程网
本站文章仅代表作者观点，不代表本站立场，所有文章非营利性免费分享。
本站提供了软件编程、网站开发技术、服务器运维、人工智能等等IT技术文章，希望广大程序员努力学习，让我们用科技改变世界。
[可靠消息最终一致(异步确保型)]http://www.zyiz.net/tech/detail-138649.html
这篇关于java 可靠消息服务_可靠消息最终一致（异步确保型）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
