RocketMQ基础知识

最新推荐文章于 2024-03-22 23:54:42 发布

LittleDragonLaw

最新推荐文章于 2024-03-22 23:54:42 发布

阅读量45

点赞数

分类专栏：分布式中间件文章标签： rocketmq

本文链接：https://blog.csdn.net/LittleDragonLaw/article/details/134319200

版权

分布式同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

中间件

2 篇文章 0 订阅

订阅专栏

RocketMQ

RocketMQ是一种开源的分布式消息中间件系统，具有高吞吐量、高可靠性、低延迟和可伸缩性等特点。

分布式消息中间件系统是一种用于在分布式系统中传递消息的软件架构。它提供了消息的可靠传递、异步通信和解耦应用程序的能力。
分布式消息中间件系统的出现是为了解决分布式系统中的消息传递和通信的挑战。

为什么会出现消息队列？

在传统的单体应用程序中，通常使用同步方式进行模块之间的通信，即一个模块调用另一个模块的函数或方法来实现通信。但在分布式系统中，由于系统的复杂性和规模，模块之间的通信变得更加困难。以下是一些导致分布式系统通信困难的因素：

异步性：分布式系统中的模块可能以异步的方式执行，并且不可预测的延迟和故障可能导致通信失败。
可靠性：在分布式环境中，网络故障、节点故障或其他错误可能导致消息丢失或重复传递。
解耦性：在大规模系统中，模块之间的解耦是重要的，以便能够独立地开发、部署和扩展模块。直接的模块间通信可能导致紧密的耦合，增加了系统的复杂性。
扩展性：分布式系统需要能够水平扩展，即增加节点数量以处理更大的负载。传统的同步通信模型可能无法有效扩展。

分布式消息中间件系统应运而生，以解决这些挑战。它提供了以下好处：

异步通信：消息中间件允许模块之间以异步的方式发送和接收消息，从而实现解耦和更高的并发性。
可靠性：消息中间件提供了消息的持久化和传递保证，确保消息不会丢失，并且可以在发生故障后进行恢复。
解耦应用程序：通过引入消息中间件，模块之间的通信变得松散耦合，每个模块只需关注自己的业务逻辑，而不需要直接依赖其他模块。
扩展性：分布式消息中间件系统可以通过添加更多的消息代理节点来实现水平扩展，以处理更大的负载。

基本概念

Producer(生产者)

Producer是消息的发送者。它将消息（消息可以包含任何类型的数据，例如文本、JSON、二进制等）发送到指定的Topic（主题）。Producer负责创建消息并将其发送到Broker。

Consumer(消费者)

Consumer是消息的接收者。它从指定的Topic订阅消息，并从Broker中拉取或接收推送消息进行处理。

Consumer Group(消费组)

每一个 consumer 实例都属于一个 consumer group，每一条消息只会被同一个 consumer group 里的一个 consumer 实例消费。（不同consumer group可以同时消费同一条消息）

Topic（主题）

Topic是消息的逻辑分类，类似于消息的主题或标签。Producer将消息发送到特定的Topic，而Consumer订阅感兴趣的Topic以接收相关消息。

Broker(消息代理服务器)

Broker是RocketMQ的核心组件，负责存储和转发消息。它接收来自Producer的消息，并将其持久化到磁盘上的消息队列中。同时，Broker也接收来自Consumer的消费请求，并返回相应的消息。

Message Queue(消息队列)

消息队列是Topic在Broker上的物理分区。每个Topic可以有多个消息队列，用于实现消息的并行处理和负载均衡。

Name Server(命名服务器)

Name Server是RocketMQ的管理节点，负责管理Broker、Topic和路由信息。Producer和Consumer通过Name Server发现和获取Broker的地址信息。

Offset（偏移量）

Offset是消息在消息队列中的唯一标识。Consumer通过记录Offset来追踪已经消费的消息位置，以便实现消息的顺序消费和容错。

Push模式和Pull模式

RocketMQ支持两种消息模式。在Push模式下，Broker推送消息给Consumer；在Pull模式下，Consumer主动从Broker拉取消息。

简单架构

RocketMQ由NameServer注册中心集群、Producer生产者集群、Consumer消费者集群和若干Broker（RocketMQ进程）组成，它的架构原理是这样的：

Broker在启动的时候去向所有的NameServer注册，并保持长连接，每30s发送一次心跳
Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择一台服务器来发送消息
Conusmer消费消息的时候同样从NameServer获取Broker地址，然后主动拉取消息来消费

消息类型

普通消息

普通消息一般应用于微服务解耦、事件驱动、数据集成等场景，这些场景大多数要求数据传输通道具有可靠传输的能力，且对消息的处理时机、处理顺序没有特别要求。

普通消息生命周期

初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
待消费：消息被发送到服务端，对消费者可见，等待消费者消费的状态。
消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。。
消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。

    @Resource
    private RocketMQTemplate rocketMQTemplate;

    @GetMapping("/rocket/send")
    public String rocketSend() {
        LocalDateTime currentTime = LocalDateTime.now();
        // 发送普通消息
        rocketMQTemplate.convertAndSend("broker-a", currentTime.toString());
        return currentTime.toString();
    }

定时/延时消息

服务端根据消息设置的定时时间在某一固定时刻将消息投递给消费者消费。

在分布式定时调度触发、任务超时处理等场景，需要实现精准、可靠的定时事件触发。

定时消息生命周期

初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
定时中：消息被发送到服务端，和普通消息不同的是，服务端不会直接构建消息索引，而是会将定时消息单独存储在定时存储系统中，等待定时时刻到达。
待消费：定时时刻到达后，服务端将消息重新写入普通存储引擎，对下游消费者可见，等待消费者消费的状态。
消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。
消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ 默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。

    @GetMapping("/rocket/delayMsg/send")
    public String rocketDelayMsgSend() {
        LocalDateTime currentTime = LocalDateTime.now();
        // 发送定时消息
        rocketMQTemplate.syncSend("rocket-topic-2:tag-2", MessageBuilder.withPayload(currentTime.toString()).build(), 2000, 3);
        return currentTime.toString();
    }

顺序消息

在有序事件处理、撮合交易、数据实时增量同步等场景下，异构系统间需要维持强一致的状态同步，上游的事件变更需要按照顺序传递到下游进行处理。在这类场景下使用 Apache RocketMQ 的顺序消息可以有效保证数据传输的顺序性。

Apache RocketMQ 的消息的顺序性分为两部分，生产顺序性和消费顺序性。

生产顺序性 ：

Apache RocketMQ 通过生产者和服务端的协议保障单个生产者串行地发送消息，并按序存储和持久化。

如需保证消息生产的顺序性，则必须满足以下条件：
- 单一生产者：消息生产的顺序性仅支持单一生产者，不同生产者分布在不同的系统，即使设置相同的消息组，不同生产者之间产生的消息也无法判定其先后顺序。
- 串行发送：Apache RocketMQ 生产者客户端支持多线程安全访问，但如果生产者使用多线程并行发送，则不同线程间产生的消息将无法判定其先后顺序。
满足以上条件的生产者，将顺序消息发送至 Apache RocketMQ 后，会保证设置了同一消息组的消息，按照发送顺序存储在同一队列中。服务端顺序存储逻辑如下：
- 相同消息组的消息按照先后顺序被存储在同一个队列。
- 不同消息组的消息可以混合在同一个队列中，且不保证连续。
消费顺序性 ：

Apache RocketMQ 通过消费者和服务端的协议保障消息消费严格按照存储的先后顺序来处理。

如需保证消息消费的顺序性，则必须满足以下条件：
- 投递顺序
  
  Apache RocketMQ 通过客户端SDK和服务端通信协议保障消息按照服务端存储顺序投递，但业务方消费消息时需要严格按照接收—处理—应答的语义处理消息，避免因异步处理导致消息乱序。
  - 备注
    
    消费者类型为PushConsumer时， Apache RocketMQ 保证消息按照存储顺序一条一条投递给消费者，若消费者类型为SimpleConsumer，则消费者有可能一次拉取多条消息。此时，消息消费的顺序性需要由业务方自行保证。
- 有限重试
  
  Apache RocketMQ 顺序消息投递仅在重试次数限定范围内，即一条消息如果一直重试失败，超过最大重试次数后将不再重试，跳过这条消息消费，不会一直阻塞后续消息处理。
  
  对于需要严格保证消费顺序的场景，请务设置合理的重试次数，避免参数不合理导致消息乱序。

顺序消息生命周期

初始化：消息被生产者构建并完成初始化，待发送到服务端的状态。
待消费：消息被发送到服务端，对消费者可见，等待消费者消费的状态。
消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ 默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。

    @GetMapping("/rocket/orderMsg/send")
    public String rocketOrderMsgSend() throws InterruptedException {
        LocalDateTime currentTime = LocalDateTime.now();
        // 发送顺序消息
        for (int i = 0; i < 5; i++) {
            Thread.sleep(1000);
            rocketMQTemplate.syncSendOrderly("rocket-topic-orderly", MessageBuilder.withPayload(LocalDateTime.now().toString()).build(), "lanceMsg");
        }
        return currentTime.toString();
    }

事务消息

事务消息是 Apache RocketMQ 提供的一种高级消息类型，支持在分布式场景下保障消息生产和本地事务的最终一致性。

消息的事务性：

Apache RocketMQ 事务消息保证本地主分支事务和下游消息发送事务的一致性，但不保证消息消费结果和上游事务的一致性。因此需要下游业务分支自行保证消息正确处理，建议消费端做好消费重试，如果有短暂失败可以利用重试机制保证最终处理成功。

事务消息处理流程

生产者将消息发送至Apache RocketMQ服务端。
Apache RocketMQ服务端将消息持久化成功之后，向生产者返回Ack确认消息已经发送成功，此时消息被标记为"暂不能投递"，这种状态下的消息即为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
- 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
- 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。

事务消息生命周期

初始化：半事务消息被生产者构建并完成初始化，待发送到服务端的状态。
事务待提交：半事务消息被发送到服务端，和普通消息不同，并不会直接被服务端持久化，而是会被单独存储到事务存储系统中，等待第二阶段本地事务返回执行结果后再提交。此时消息对下游消费者不可见。
消息回滚：第二阶段如果事务执行结果明确为回滚，服务端会将半事务消息回滚，该事务消息流程终止。
提交待消费：第二阶段如果事务执行结果明确为提交，服务端会将半事务消息重新存储到普通存储系统中，此时消息对下游消费者可见，等待被消费者获取并消费。
消费中：消息被消费者获取，并按照消费者本地的业务逻辑进行处理的过程。此时服务端会等待消费者完成消费并提交消费结果，如果一定时间后没有收到消费者的响应，Apache RocketMQ会对消息进行重试处理。
消费提交：消费者完成消费处理，并向服务端提交消费结果，服务端标记当前消息已经被处理（包括消费成功和失败）。 Apache RocketMQ默认支持保留所有消息，此时消息数据并不会立即被删除，只是逻辑标记已消费。消息在保存时间到期或存储空间不足被删除前，消费者仍然可以回溯消息重新消费。
消息删除：Apache RocketMQ按照消息保存机制滚动清理最早的消息数据，将消息从物理文件中删除。

@RocketMQTransactionListener
public class TransactionMsgListener implements RocketMQLocalTransactionListener
{
    private Logger logger = LoggerFactory.getLogger(getClass());

    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object o) {
        logger.info("start invoke local rocketMQ transaction");
        RocketMQLocalTransactionState resultState = RocketMQLocalTransactionState.COMMIT;
        try
        {
            //处理业务
            String jsonStr = new String((byte[]) msg.getPayload(), StandardCharsets.UTF_8);
            logger.info("invoke msg content：{}",jsonStr);
        }
        catch (Exception e)
        {
            logger.error("invoke local mq trans error",e);
            resultState = RocketMQLocalTransactionState.UNKNOWN;
        }

        return resultState;
    }

    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
        logger.info("start check Local rocketMQ transaction");
        RocketMQLocalTransactionState resultState = RocketMQLocalTransactionState.COMMIT;
        try
        {
            String jsonStr = new String((byte[]) msg.getPayload(), StandardCharsets.UTF_8);
            logger.info("check trans msg content：{}",jsonStr);
        }
        catch (Exception e)
        {
            resultState  = RocketMQLocalTransactionState.ROLLBACK;
        }
        return resultState;
    }
}

    @GetMapping("/rocket/txMsg/send")
    public String rocketTransMsgSend() {
        Message message =new Message();
        message.setBody("this is tx message".getBytes());
        TransactionSendResult result=rocketMQTemplate.sendMessageInTransaction("test-tx-rocketmq",
                MessageBuilder.withPayload(message).build(), "hashKey");

        //发送状态
        String sendStatus = result.getSendStatus().name();
        // 本地事务执行状态
        String localTxState = result.getLocalTransactionState().name();
        return sendStatus;

    }

LittleDragonLaw

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
RocketMQ基础知识

Apache RocketMQ 通过客户端SDK和服务端通信协议保障消息按照服务端存储顺序投递，但业务方消费消息时需要严格按照接收—处理—应答的语义处理消息，避免因异步处理导致消息乱序。Apache RocketMQ 顺序消息投递仅在重试次数限定范围内，即一条消息如果一直重试失败，超过最大重试次数后将不再重试，跳过这条消息消费，不会一直阻塞后续消息处理。满足以上条件的生产者，将顺序消息发送至 Apache RocketMQ 后，会保证设置了同一消息组的消息，按照发送顺序存储在同一队列中。
复制链接

扫一扫