RocketMQ 基础入门

RocketMQ是一个统一消息引擎，轻量级的数据处理平台。通俗的讲，当你需要一个消息处理框架，可以考虑选它。

本文基本来自附录中所列参考文档，作为我的笔记，感兴趣的可以直接跳到参考文档，或者直接跳转github RocketMQ官方文档，略过本文

RocketMQ有那些特性

消息类型

• 事务消息：应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。通过事务消息能达到分布式事务的最终一致性
• 定时消息：消息发送出去后，不会被立即消费，而是等到指定的时间点才会消费
• 延时消息：消息发送出去后，不会被立即消费，而是等到过了指定的一段时间（从发送开始经过固定的一段时间）后才消费
• 顺序消息：先发布的消息一定会先被消费，支持全局顺序消息和分区顺序消息
  • 全局顺序消息：所有消息按照严格的先入先出的顺序发布和消费
  • 分区顺序消息：同一个分区的消息严格按照先入先出的顺序发布和消费，分区字段是Sharding Key
• 普通消息：无上述消息特性

消息特性:

• 消息至少投递一次(At least once):消费者消费完成后，才会返回ACK，如果没有消费一定不会ACK
• 消息重试：消费失败后，考虑到异常恢复起来需要一些时间，设置了多个重试的级别，每个重试级别都有与之对应的重新投递时延，重试次数越多投递延时越大
• 消息过滤：消费者可以根据Tag进行消息过滤
• 消息查询：消费遇到问题，可以通过Message ID、Message Key和Topic来查询消息
• 消息回溯：能自定义时间或位点重新消费已经消费的消息或者丢弃堆积的消息
• 流控：生产（流控后，不会尝试消息重投）或消费（降低拉取频率）达到瓶颈，都能进行流控
• 死信队列：达到最大的重试次数后，如果还无法成功，此时不会立刻丢弃消息，而是送到死信队列，可以对死信队列的消息进行特定的处理

RocketMQ的架构与核心概念

概念

• Message: 消息队列中消息传递的载体，生产和消费数据的最小单位
• Message Id: 消息的全局唯一标识，唯一标识某条消息，由RocketMQ生成
• Message Key: 消息的业务标识，有消息生产者设置，唯一标识某个业务逻辑
• Topic:一类消息的集合，每个主题包含若干条消息，每个消息必须属于一个主题，且只能属于一个主题，是RocketMQ进行消息订阅的基本单位
• Tag:用于同一Topic下区分不同类型的消息
• Producer: 消息生产者
• Producer Group: 同一类Producer的集合，他们发送同一类消息，且发送逻辑一致
• Consumer: 消息发送者
• Consumer Group: 同一类Consumer的集合，他们消费同一类消息，且消费逻辑一致
• Group Id: Group的标识

架构

image.png

• Producer:消息生产者，负责生产并发送消息
• Consumer:消息消费者，负责接收并消费消息
• NameServer:Topic路由注册消息，每个NameServer保存关于Broker集群的整个路由信息和用于客户端查询的队列信息
• Broker:负责消息的存储、投递和查询以及保证服务的高可用
• Broker Discovery: Producer发送消息时，需要知道发送给那个Broker投递，默认从本地缓存拿，如果缓存没有就从NameServer上重新拉取（Consumer类似）
• Routing Info: Broker启动后，会将自己注册到NameServer,并每隔一段时向NameServer上报Topic路由信息

为什么选择RocketMQ

RocketMQ团队一开始使用的是ActiveMQ,但是随着队列、topic的增加，ActiveMQ IO模型达到了它的瓶颈，于是开始考虑kafka是否合适，但是，在低延时和高可用上，kafka并没有达到要求，因此决定研发新的RocketMQ。

原因阐述来自RocketMQ团队，一般来说希望对比”绝对公平、公正“，但是出自RocketMQ团队，也需要思考下是否带有”偏心“的色彩。

RocketMQ vs ActiveMQ vs Kafka

image.png

参考

RocketMQ github基本概念 RocketMQ github功能特性 RocketMQ github架构设计 RocketMQ github设计 阿里云-RocketMQ文档-名词解释 阿里云-RocketMQ文档-功能特性 Apache RocketMQ-为什么使用RocketMQ