RocketMQ知识整理-公开
2021-08-18 15:00:40 21 举报
AI智能生成
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
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可用了
DefaultMQPushConsumer
consumerGroup
messageModel
CLUSTERING //集群消费模式
BROADCASTING //广播消费模式
consumeFromWhere
consumeTimestamp
allocateMessageQueueStrategy
AllocateMessageQueueAveragely //取模平均
AllocateMessageQueueAveragelyByCircle //环形平均
AllocateMessageQueueByConfig // 按照配置,传入的messageQueueList
AllocateMessageQueueByMachineRoom //按机房,从源码上看,必须和阿里的某些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会等同于消费失败来处理
DefaultMQPullConsumer
registerTopics
allocateMessageQueueStrategy
Message数据结构
Broker 使用指南
配置
Broker集群搭建
Broker重启对客户端的影响
水平扩展及负载均衡
commit log
message queue本身并不存储消息。真正的消息存储会写在CommitLog的文件,
message queue只是存储CommitLog中对应的位置信息,方便通过message queue找到对应存储在CommitLog的消息。
Producer
默认会轮询所有的message queue发送,以达到让消息平均落在不同的queue上。
Consumer负载均衡
其他
零拷贝原理
生产者
消费者
消息模式
集群模式
广播模式
消息过滤
简单消息过滤
Tag
高级消息过滤
FilterServer
重试策略
originMsgId
消息id变化,但是原始id不变
RocketMQ 服务发现(Name Server)
RocketMQ 通信组件
管理员命令
最佳实践
Producer
发送消息注意事项
一个应用尽可能用一个Topic,消息子类型用tags来标识
每个消息在业务局面的唯一标识码
日志务必要打印sendresult和key字段
对于消息不可丢失应用,务必要有消息重収机制
消息发送失败如何处理
重试
某些场景选择oneway形式发送
发送顺序消息注意事项
consumer
消费过程要做到幂等(即消费端去重)
消费失败处理方式
消费速度慢处理方式
提高消费并行度
批量方式消费
跳过非重要消息
如何判断消费収生了堆积,offset计算
优化每条消息消费过程
消费打印日志
场景
解耦
异步
提高接收能力
并行
最终一致
削峰填谷
收藏
收藏
0 条评论
下一页