RocketMQ知识整理-公开

简介

特点

Netty NIO

不使用ZK而是NameServer

集群，负载均衡，水平扩展，广播

丰富的消息机制，顺序消息，事务（开源不支持）

丰富的消息拉取模式

亿级堆积

消息失败重试

高可用

可查询

概念

集群消费

广播消费

顺序消息

普通顺序消息

严格顺序消息

物理部署

逻辑部署

术语

Producer

开源版本并不支持事务消息

Message Queue

Consumer

PushConsumer

PullConsumer

Message

Topic

Tag

Offset

Group

Broker

JMS中的Provider

Name Server

组件

NameServer

Name Server是RocketMQ的寻址服务。用于把Broker的路由信息做聚合。用户端依靠Name Server决定去获取对应topic的路由信息，从而决定对哪些Broker做连接。

Name Server是一个几乎无状态的结点，Name Server之间采取share-nothing的设计，互不通信。

Name Server所有状态都从Broker上报而来，本身不存储任何状态，所有数据均在内存。

Broker向所有的NameServer结点建立长连接，注册Topic信息。

Filter Server

使用 Java class上传作为过滤表达式是一个双刃剑——一方面方便了应用的过滤操作且节省网卡资源，另一方面也带来了服务器端的安全风险。

集群

单master模式

多master模式

多master多slave异步复制模式

多master多slave同步双写模式

存储特点

零拷贝

mmap+write

文件系统

ext4

数据存储结构

消费队列服务

消息索引服务

事务状态服务

定时消息服务

客户端使用指南(配置)

ClientConfig

ClientConfig 为客户端的公共配置类

继承

DefaultMQAdminExt

DefaultMQProducer

DefaultMQPullConsumer

DefaultMQPushConsumer

配置

namesrvAddr

instanceName

RocketMQ用一个叫ClientID的概念，来唯一标记一个客户端实例，一个客户端实例对于Broker而言会开辟一个Netty的客户端实例。

persistConsumerOffsetInterval

由于持久化不是立刻持久化的，所以如果消费实例突然退出（如断点）、或者触发了负载均衡分consue queue重排，有可能会有已经消费过的消费进度没有及时更新而导致重新投递。故本配置值越小，重复的概率越低，但同时也会增加网络通信的负担。

vipChannelEnabled

broker的netty server会起两个通信服务。两个服务除了服务的端口号不一样，其他都一样。其中一个的端口（配置端口-2）作为vip通道，客户端可以启用本设置项把发送消息此vip通道。

DefaultMQProducer

producerGroup

createTopicKey

defaultTopicQueueNums

sendMsgTimeout

TransactionMQProducer

事务消息机制

事务生产者，截至至4.1，由于暂时事务回查功能缺失，整体并不完全可用

4.3可用了

consumerGroup

messageModel

CLUSTERING //集群消费模式

BROADCASTING //广播消费模式

consumeFromWhere

consumeTimestamp

allocateMessageQueueStrategy

AllocateMessageQueueAveragely //取模平均AllocateMessageQueueAveragelyByCircle //环形平均AllocateMessageQueueByConfig // 按照配置，传入的messageQueueListAllocateMessageQueueByMachineRoom //按机房，从源码上看，必须和阿里的某些broker命名一致才行AllocateMessageQueueConsistentHash //一致性哈希算法。用于解决“惊群效应”。

subscription

messageListener

offsetStore

若没有显示设置的情况下，广播模式将使用LocalFileOffsetStore，集群模式将使用RemoteBrokerOffsetStore，不建议修改。

consumeThreadMin

consumeThreadMax

consumeConcurrentlyMaxSpan

并发消费下，单条consume queue队列允许的最大offset跨度，达到则触发流控

注：只对并发消费（ConsumeMessageConcurrentlyService）生效

pullInterval

pullBatchSize

幂等去重策略

maxReconsumeTimes

一个消息如果消费失败的话，最多重新消费多少次才投递到死信队列

注，这个值默认值虽然是-1，但是实际使用的时候默认并不是-1。按照消费是并行还是串行消费有所不同的默认值。

并行：默认16次

串行：默认无限大（Interge.MAX_VALUE）。由于顺序消费的特性必须等待前面的消息成功消费才能消费后面的，默认无限大即一直不断消费直到消费完成。

consumeTimeout

消费的最长超时时间。默认15分钟

如果消费超时，RocketMQ会等同于消费失败来处理

registerTopics

Message数据结构

Broker 使用指南

Broker集群搭建

Broker重启对客户端的影响

水平扩展及负载均衡

commit log

message queue本身并不存储消息。真正的消息存储会写在CommitLog的文件，message queue只是存储CommitLog中对应的位置信息，方便通过message queue找到对应存储在CommitLog的消息。

默认会轮询所有的message queue发送，以达到让消息平均落在不同的queue上。

Consumer负载均衡

其他

零拷贝原理

生产者

消费者

消息模式

集群模式

广播模式

消息过滤

简单消息过滤

高级消息过滤

FilterServer

重试策略

originMsgId

消息id变化，但是原始id不变

RocketMQ 服务发现（Name Server）

RocketMQ 通信组件

管理员命令

最佳实践

发送消息注意事项

一个应用尽可能用一个Topic，消息子类型用tags来标识

每个消息在业务局面的唯一标识码

日志务必要打印sendresult和key字段

对于消息不可丢失应用，务必要有消息重収机制

消息发送失败如何处理

重试

某些场景选择oneway形式发送

发送顺序消息注意事项

consumer

消费过程要做到幂等（即消费端去重）

消费失败处理方式

消费速度慢处理方式

提高消费并行度

批量方式消费

跳过非重要消息

如何判断消费収生了堆积，offset计算

优化每条消息消费过程

消费打印日志

场景

解耦

异步

提高接收能力

并行

最终一致

削峰填谷

RocketMQ