微服务架构下，您是否常面临如下挑战？
1 通讯机制更为复杂
单体应用改造为分布式系统后，应用间的通讯机制及故障处理变得复杂。
2 系统应用之间依赖强
各个业务模组之间通过串联消息通讯，彼此之间相互影响且依赖性强，可用性差。
3 数据一致性难以保障
微服务化后，简单功能需要调用多个服务并操作多个数据库实现，数据一致性难以保障。
MQ事务消息，帮助实现类似 X/Open XA 的分布事务功能，达到分布式事务的最终一致。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
什么是事务消息？
通过消息的异步事务，可以保证本地事务和消息发送同时执行成功或失败，既能实现系统之间的解耦，又能保证数据的最终一致性，广泛应用于电商交易系统、支付红包等场景。
相较于传统事务而言，MQ分布式事务具有无可比拟的优势
MQ事务消息交互流程
事务消息,可以认为是两阶段提交消息的实现，保证执行本地事务的执行和消息发送的原子性，确保分布式系统中的最终一致性。消息队列 RocketMQ 版提供的分布式事务消息适用于所有对数据最终一致性有强需求的场景。本文介绍消息队列 RocketMQ 版事务消息的概念、优势、典型场景、交互流程以及使用过程中的注意事项。
事务消息：消息队列 RocketMQ 版提供类似 X/Open XA 的分布式事务功能，通过消息队列 RocketMQ 版事务消息能达到分布式事务的最终一致。
半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到了消息队列 RocketMQ 版服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该询问过程即消息回查。
新用户 9.9 元尝鲜体验
