02 MQ模型 事务消息

消息队列模型：

①队列模型（点对点）：生产者-消费者，一条消息只能被一个消费者消费到
②发布订阅模型：发布者-订阅者。

RocketMQ模型（Kafka模型也是一样的）

1. RocketMQ中有生产者、消费者、主题等概念，每个主题可以包含多个队列，通过多个队列来实现并行生产和消费。这种情况下，只能在队列上保证消息的有序性，在主题层面无法保证消息顺序消费。
2. RocketMQ中使一条消息能被多个消费者消费是通过消费组来实现的。在一个消费组中的多个消费者不能消费同一条消息，（同一个组内的消费者是竞争消费关系）但是一条消息可以被多个消费组消费。
3. 由于消息需要被不同的消费组进行多次消费，所以RocketMQ在队列上为每个消费组维护了一个消费位置，每成功消费一条消息，位置就加一。
   

事务消息，为什么消息队列需要事务？

消息队列中的事务，主要就是用来解决消息生产者和消息消费者的数据一致性问题。

• 假设一个下单过程，锁定库存成功后发消息到消息队列，订单系统收到消息去做订单入库操作。那么会有这两种可能，库存锁定成功，消息发送失败。库存锁定失败，消息发送成功。这两种情况都有可能造成数据不一致问题。所以就需要事务来保证这两个操作要么全部执行成功，要么全部失败。在分布式系统中要用分布式事务。

• 比较常见的分布式事务实现有2PC（二阶段提交）、TCC（Try-Confirm-Cancel）和事务消息。每一种都有其特定的使用场景。

• 事务消息使用的场景主要是那些需要异步更新数据，并且对数据实时性要求不太高的场景。事务消息需要消息队列提供相应的功能才能实现，具体实现如下：

1. 首先，订单系统（生产者）在消息队列上开启一个事务，然后订单系统给消息服务器发送一个“半消息”，这个半消息包含了完整的消息内容，只不过它在事务提交之前，对于消费者是不可见的。
2. 半消息发送成功后，订单系统就可以执行本地事务了，然后根据本地事务的执行结果决定提交或者回滚事务消息。如果本地事务执行成功，就提交事务消息，消费者就可以看到这条消息。如果本地事务执行失败，那就回滚事务消息，消费者就不会收到这条消息。这样就实现了要么都成功，要么都失败。

如果提交或回滚事务消息时失败了怎么办？

1. RocketMQ增加了事务反查机制来解决事务消息提交失败的问题。如果订单系统（生产者）在提交或者回滚事务消息时发生网络异常，导致Broker没有收到提交或者回滚的请求，Broker会定期去Producer上去反查这个事务对应的本地事务的状态，然后根据反查结果决定提交或者回滚这个事务。
2. 为了支撑这个反查机制，我们的业务代码需要实现一个反查本地事务状态的接口，返回本地事务是执行成功还是失败。