介绍

RocketMQ 作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。

基础概念

• Producer： 消息生产者，负责产生消息，一般由业务系统负责产生消息

• Consumer：消息消费者，负责消费消息，一般是后台系统负责异步消费

• Topic： 是一类消息的集合，是消息的类别（业务分类）一个 topic 可以绑定在多个服务器（Broker）上，生产者发送消息时按照一定策略发送到某一 Broker 上

• Tag（标签）

  • 一个 tag 属于一个 topic，一个 topic 含有多个 tag

  • 每个消息可以被打上不同的  tag，并且每个消费者可以选择消费特定  tag  的消息，多个消费者也可以同时消费同一个  tag  的消息。一个  tag  并不限定只有一个队列可以消费。

  • 生产者向 tag 中写入数据，消费者从一个 tag 中读取数据

  也可以直接将消息发送到 topic 中，向整个主题发送消息

• Queue（队列）：消息队列，是负载均衡过程中资源分配的基本单元。

• Group：一类生产者或消费者，这类生产者或消费者通常生产或消费同一类消息，且消息发布或订阅的逻辑一致

  • 生产者组指的是一组生产者应用程序，它们共同向一个主题（topic）发送消息。
  • 消费者组指的是一组消费者应用程序，它们共同从一个主题（topic）接收消息。
  • 消费者组中每个消费者可以分配得到多个 Queue，每个 Queue 只有一个消费者。当一个消费者宕机时，RocketMQ 会从这个消费者组中分配其他消费者，以确保消息被及时处理，实现可伸缩性和容错性。

• Message：生产者向Topic发送并最终传送给消费者的数据消息的载体。

RocketMQ特性

发送方式

Sync：同步的发送方式，会等待发送结果后才返回

Async：异步的发送方式，发送完后，立刻返回。Client 在拿到 Broker 的响应结果后，会 回调指定的 callback. 该 API 也可以指定 Timeout，不指定时默认为 3000ms.

Oneway：发送后，直接返回。

发送结果

SEND_OK

发送消息成功并不意味着消息的可靠性。为了确保消息不会丢失，建议启用同步Master服务器或同步刷盘选项，即SYNC_MASTER或SYNC_FLUSH。

FLUSH_DISK_TIMEOUT

消息成功发送，但服务器在刷盘时遇到了超时的问题。消息已经被存储在服务器队列（内存）中，只有在服务器宕机时才会丢失。在消息存储配置中，可以设置刷盘方式和同步刷盘的时间长度。如果Broker服务器的刷盘方式为同步刷盘，即FlushDiskType=SYNC_FLUSH（默认为异步刷盘方式），在同步刷盘的时间内（默认为5秒）如果服务器无法完成刷盘，将会返回"刷盘超时"的状态。

FLUSH_SLAVE_TIMEOUT

消息发送成功，但是服务器同步到Slave时超时。此时消息已经进入服务器队列，只有 服务器宕机，消息才会丢失。如果Broker服务器的角色是同步Master，即 SYNC_MASTER（默认是异步Master即ASYNC_MASTER），并且从Broker服务器未在同 步刷盘时间（默认为5秒）内完成与主服务器的同步，则将返回该状态——数据同步到 Slave服务器超时。

SLAVE_NOT_AVAILABLE

消息发送成功，但是此时Slave不可用。如果Broker服务器的角色是同步Master，即 SYNC_MASTER（默认是异步Master服务器即ASYNC_MASTER），但没有配置slave Broker服务器，则将返回该状态——无Slave服务器可用。

总结

最近刚开始接触RocektMQ，只是简单的使用，对功能如何实现还很迷茫 准备在接下来的一段时间进一步学习和理解。