Apache RocketMQ 5.0 消息进阶：如何支撑复杂的业务消息场景?

一致性

首先来看 RocketMQ 的第一个特性-事务消息，事务消息是 RocketMQ 与一致性相关的特性，也是 RocketMQ 有别于其他消息队列的最具区分度的特性。

以大规模电商系统为例，付款成功后会在交易系统中订单数据库将订单状态更新为已付款。然后交易系统再发送一条消息给 RocketMQ，RocketMQ 将订单已付款的事件通知给所有下游应用，保障后续的履约环节。

但上述流程存在一个问题，交易系统写数据库与发消息互相分开，它不是一个事务，会出现多种异常情况，比如数据库写成功但消息发失败，这个订单的状态下游应用接收不到，对于电商业务来说，可能造成大量用户付款但卖家不发货的情况；而如果先发消息成功再写数据库失败，会造成下游应用认为订单已付款，推进卖家发货，但是实际用户未付款成功。这些异常都会对电商业务造成大量脏数据，产生灾难性业务后果。

而 RocketMQ 事务消息的能力可以保障生产者的本地事务（如写数据库）、发消息事务的一致性，最后通过 Broker at least once 的消费语义，保证消费者的本地事务也能执行成功，最终实现生产者、消费者对同一业务的事务状态达到最终一致。

一致性：事务消息-原理

如下图所示，事务消息主要通过两阶段提交+事务补偿机制结合实现。

首先生产者会发送 half 消息，也就是 prepare 消息，broker 会把 half 存到队列中。接下来生产者执行本地事务，一般是写数据库，本地事务完成后，会往 RocketMQ 发送 commit 操作，RocketMQ 会把 commit 操作写入 OP 队列，并进行 compact，把已提交的消息写到 ConsumeQueue 对消费者可见。反过来如果是 rollback 操作，则会跳过对应的 half 消息。

面对异常的情况，比如生产者在发送 commit 或者 rollback 之前宕机了，RocketMQ broker 还会有补偿检查机制，定期回查 Producer 的事务状态，继续推进事务。

无论是 Prepare 消息、还是 Commit/Rollback 消息、或者是 compact 环节，在存储层面都是遵守 RocketMQ 以顺序读写为主的设计理念，达到最优吞吐量。

一致性：事务消息 demo

接下来来看一个事务消息的简单示例。使用事务消息需要实现一个事务状态的查询器，这也是和普通消息一个最大的区别。如果我们是一个交易系统，这个事务