当消息队列和事务联系在一起时，它指的是消息生产者和消息消费者之间如何保持数据一致性。

什么是分布式事务？

事务是指当我们进行若干项数据更新操作时，为了保证数据的完整性和一致性，我们希望这些更新操作要么都成功，要么都失败。而更新的数据，并不局限于数据库中的数据，它可以是磁盘上的文件，也可以是一个远程服务，或者以其他形式存储的数据。

事务会有四个特性，俗称ACID：

• 原子性（A)，一个事务操作不可分割，要么成功，要么失败。
• 一致性（C），指数据在事务执行完成的时间之前，读到的一定是更新前的数据，之后读到的一定是更新后的数据，不存在一个时刻，让用户读到更新过程中的数据。
• 隔离性（I），一个事务的执行不应该被其他事务干扰。
• 持久性（D），一个事务一旦完成提交，后续的其他操作和故障都不会对事务的结果产生影响。

对于分布式系统来说，严格实现ACID几乎是不可能的，或者说代价太过，因此，我们在保证可用性和不严重牺牲性能的前提下，实现数据一致性已经很困难，因此，出现了很多变种，例如顺序一致性、最终一致性等。

目前大家所说的分布式事务，更多情况下，是在分布式系统中事务的不完整实现，在不同的应用场景中，有不同的实现，目的都是通过一些妥协来解决实际问题。

在实际应用中，比较常见的分布式事务有2PC（Two-phase Commit，二阶段提交）、TCC（Try-Confirm-Cancel）和事务消息。

事务消息使用的场景主要是那些需要异步更新数据，并且对数据实时性要求不太高的场景。

消息队列如何实现分布式事务？

事务消息需要消息队列提供相应的功能才能实现，Kafka和RocketMQ都提供了事务相关功能。

下面以下订单为例，说明一下如何使用消息队列实现分布式事务。

首先，订单系统在消息队列上开启一个事务，然后订单系统给消息服务器发送一个“半消息”，这个半消息不是说消息内容不完整，它包含完整的消息内容。半消息和普通消息的唯一区别，是在事务提交之前，对于消费者来说，这个消息时不可见的。

半消息发送成功后，订单系统就可以执行本地事务了，在订单中创建一条订单记录，并提交订单库的数据库事务。然后根据本地事务的执行结果决定提交或者回滚事务消息。如果订单创建成功，那么就提交事务消息，购物车系统就可以消费到这条消息继续后续的流程。如果订单创建失败，就回滚消息，购物车系统就不会受到这条消息。这样基本实现了“要么都成功，要么都失败”的一致性要求。

那么当提交事务消息时失败了，应该怎么处理呢？对于这种情况，Kakfa的解决方案比较简单粗暴，直接抛出异常，让用户自行处理。RocketMQ会使用事务反查的机制来解决事务消息提交失败的问题。订单系统作为Producer，在提交或者回滚事务消息时发生网络异常，RocketMQ的Broker没有收到提交或者回滚的请求，Broker会定期去Producer上反查这个事务对应的本地事务的状态，然后根据反查结果决定提交或者回滚这个事务。

我们的业务代码中需要实现一个反查本地事务状态的街口，告知RocketMQ本地事务是成功还是失败。

下面是用RocketMQ进行事务处理的流程图。