一个严格意义的事务实现，应该具有 4 个属性：原子性、一致性、隔离性、持久性。这四
个属性通常称为 ACID 特性。
原子性，是指一个事务操作不可分割，要么成功，要么失败，不能有一半成功一半失败的情况。
一致性，是指这些数据在事务执行完成这个时间点之前，读到的一定是更新前的数据，之后读到的一定是更新后的数据，不应该存在一个时刻，让用户读到更新过程中的数据。
隔离性，是指一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对正在进行的其他事务是隔离的，并发执行的各个事务之间不能互相干扰，这个有点儿像我们打网游中的副本，我们在副本中打的怪和掉的装备，与其他副本没有任何关联也不会互相影响。
持久性，是指一个事务一旦完成提交，后续的其他操作和故障都不会对事务的结果产生任何影响。
分布式事务
在实际应用中，比较常见的分布式事务实现有 2PC（Two-phase Commit，也叫二阶段提
交）、TCC(Try-Confirm-Cancel) 和事务消息。每一种实现都有其特定的使用场景，也有
各自的问题，都不是完美的解决方案。
消息队列是如何实现分布式事务的？
事务消息需要消息队列提供相应的功能才能实现，Kafka 和 RocketMQ 都提供了事务相关
功能。
首先，订单系统在消息队列上开启一个事务。然后订单系统给消息服务器发送一个“半消
息”，这个半消息不是说消息内容不完整，它包含的内容就是完整的消息内容，半消息和普
通消息的唯一区别是，在事务提交之前，对于消费者来说，这个消息是不可见的。
半消息发送成功后，订单系统就可以执行本地事务了，在订单库中创建一条订单记录，并提交订单库的数据库事务。然后根据本地事务的执行结果决定提交或者回滚事务消息。如果订单创建成功，那就提交事务消息，购物车系统就可以消费到这条消息继续后续的流程。如果订单创建失败，那就回滚事务消息，购物车系统就不会收到这条消息。这样就基本实现了“要么都成功，要么都失败”的一致性要求。
但是存在一个问题，这个实现过程中，有一个问题是没有解决的。如果在第四步提交事务消息时失败了怎么办？对于这个问题，Kafka 和 RocketMQ 给出了 2 种不同的解决方案。
Kafka 的解决方案比较简单粗暴，直接抛出异常，让用户自行处理。我们可以在业务代码中反复重试提交，直到提交成功，或者删除之前创建的订单进行补偿。RocketMQ 则给出了另外一种解决方案。
RocketMQ 中的分布式事务实现
在 RocketMQ 中的事务实现中，增加了事务反查的机制来解决事务消息提交失败的问题。
如果 Producer 也就是订单系统，在提交或者回滚事务消息时发生网络异常，RocketMQ
的 Broker 没有收到提交或者回滚的请求，Broker 会定期去 Producer 上反查这个事务对
应的本地事务的状态，然后根据反查结果决定提交或者回滚这个事务。
为了支撑这个事务反查机制，我们的业务代码需要实现一个反查本地事务状态的接口，告知RocketMQ 本地事务是成功还是失败。
在我们这个例子中，反查本地事务的逻辑也很简单，我们只要根据消息中的订单 ID，在订
单库中查询这个订单是否存在即可，如果订单存在则返回成功，否则返回失败。
RocketMQ 会自动根据事务反查的结果提交或者回滚事务消息。
这个反查本地事务的实现，并不依赖消息的发送方，也就是订单服务的某个实例节点上的任何数据。这种情况下，即使是发送事务消息的那个订单服务节点宕机了，RocketMQ 依然可以通过其他订单服务的节点来执行反查，确保事务的完整性。
综合上面讲的通用事务消息的实现和 RocketMQ 的事务反查机制，使用 RocketMQ 事务
消息功能实现分布式事务的流程如下图：