02 MQ模型事务消息

系统管理员 2022-11-26 01:57 175阅读 0赞

#### 消息队列模型： ####

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

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

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

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

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

*  假设一个下单过程，锁定库存成功后发消息到消息队列，订单系统收到消息去做订单入库操作。那么会有这两种可能，库存锁定成功，消息发送失败。库存锁定失败，消息发送成功。这两种情况都有可能造成数据不一致问题。所以就需要事务来保证这两个操作要么全部执行成功，要么全部失败。在分布式系统中要用分布式事务。
 *  比较常见的分布式事务实现有2PC（二阶段提交）、TCC（Try-Confirm-Cancel）和事务消息。每一种都有其特定的使用场景。
 *  事务消息使用的场景主要是那些需要异步更新数据，并且对数据实时性要求不太高的场景。事务消息需要消息队列提供相应的功能才能实现，具体实现如下：

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

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

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzMzODUxOQ_size_16_color_FFFFFF_t_70]: /images/20221124/72a35ccbfa5b4495949a0ea11aa03769.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzMzODUxOQ_size_16_color_FFFFFF_t_70 1]: /images/20221124/3731734e3cd24999bb66e35b6d8522c7.png