RocketMQ
2021-01-29 23:32:29 44 举报
AI智能生成
RocketMQ学习思维导图
作者其他创作
大纲/内容
基本概念
消息模型(Message Model)
由 Producer、Broker、Consumer 三部分组成,其中Producer 负责生产消息,Consumer 负责消费消息,Broker 负责存储消息
消息生产者(Producer)
同步发送、异步发送、顺序发送、单向发送
消息消费者(Consumer)
拉取式消费、推动式消费
主题(Topic)
每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位
代理服务器(Broker Server)
消息中转角色,负责存储消息、转发消息
名字服务(Name Server)
拉取式消费(Pull Consumer)
推动式消费(Push Consumer)
生产者组(Producer Group)
消费者组(Consumer Group)
集群消费(Clustering)
相同Consumer Group的每个Consumer实例平均分摊消息
广播消费(Broadcasting)
相同Consumer Group的每个Consumer实例都接收全量的消息
普通顺序消息(Normal Ordered Message)
严格顺序消息(Strictly Ordered Message)
消息(Message)
标签(Tag)
特性(features)
订阅与发布
消息顺序
消息过滤
消息可靠性
Broker非正常关闭
Broker异常Crash
OS Crash
机器掉电,但是能立即恢复供电情况
机器无法开机(可能是cpu、主板、内存等关键设备损坏)
磁盘设备损坏
Broker异常Crash
OS Crash
机器掉电,但是能立即恢复供电情况
机器无法开机(可能是cpu、主板、内存等关键设备损坏)
磁盘设备损坏
至少一次
回溯消费
事务消息
应用本地事务和发送消息操作可以被定义到全局事务中,要么同时成功,要么同时失败。RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能,通过事务消息能达到分布式事务的最终一致
定时消息
消息重试
消息重投
流量控制
死信队列
死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败,消息队列会自动进行消息重试;达到最大重试次数后,若消费依然失败,则表明消费者在正常情况下无法正确地消费该消息,此时,消息队列 不会立刻将消息丢弃,而是将其发送到该消费者对应的特殊队列中。
架构原理
Broker
作用:存储转发消息。每个borker可以有自己的副本slave。
每隔30秒发送心跳到NameServer中
存储
所有topic都写入同一个文件中
为每一个消费者组存储消费topic最后一个offset单独存储(consume queue)
物理存储
commit log
comsume queue
index file
PageCache
零拷贝
内存映射(Memery Map)mmap
Topic
可以根据tag之类过滤消息
NameServer
Broker会注册到NameServer,Producer和Consumer用NameServer来发现Broker
每隔10秒检查Broker的最新心跳时间,如果超过120S都没有发送心跳,则从路由中移除
实现了AP,可用性(Availability)、分区容错性(Partition tolerance)
Zookeeper实现了CP,一致性(Consistency)、分区容错性(Partition tolerance)
Producer和Consumer每隔30秒拉取NameServer上的信息。ScheduleAtFixRate
Producer
每隔30秒拉取NameServer上路由信息
消息发送规则
SelectMessageQueueByHash(默认)自增轮询方式
SelectMessageQueueByRandom随机选择一个队列
SelectMessageQueueByMachineRoom 返回空
自定义实现MessageQueueSelector
顺序消息
生产者发送消息到达broker是有序,不能使用多线程发送,需要顺序发送
写入broker的时候顺序写入,相同主体集中写入,选择同一个queue,MessageQueueSelector传入相同的hashKey
消费者消费的时候只能有一个线程
事务消息
延迟消息
定时消息(延迟队列)是指消息发送到broker后,不会立即被消费,等待特定时间投递给真正的topic。 broker有配置项messageDelayLevel,默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”,18个level。可以配置自定义messageDelayLevel
定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中,并根据delayTimeLevel存入特定的queue,queueId = delayTimeLevel – 1,即一个queue只存相同延迟的消息,保证具有相同发送延迟的消息能够顺序消费。broker会调度地消费SCHEDULE_TOPIC_XXXX,将消息写入真实的topic
Consumer
消费方式
集群模式
广播模式
消费模式
PULL
通过长轮询在没有消息时Hold住请求
PUSH
注册MessageListener监听器
负载均衡
连续分配(默认)AllocateMessageQueueAveragely
轮流:AllocateMessageQueueAveragelyByCircle
通过配置:AllocateMessageQueueByConfig
一致性Hash:AllocateMessageQueueConsistentHash
指定一个broker的topic中的queue:AllocateMessageQueueByMachineRoom
按broker的机房就近:AllocateMachineRoomNearBy
消费者重试及死信队列
重试时间不对衰减,最多重试16次
MessageQueue
默认8个队列
高可用
主从同步
意义
数据备份
高可用
提高性能
消费实时
数据同步
集群名字相同,连接到相同NameServer,brokerId=0代表master,1代表slave
刷盘类型
主从异步复制
主从同步双写
异步刷盘
同步刷盘
主从同步流程
从服务建立TCP连接主服务器,每隔5S向主服务器发送commitLog文件最大偏移量拉取还未同步消息
主服务器开启监听端口,监听从服务器发送过来的消息,解析并返回查找出未同步的消息给从服务器
客户端收到主服务器的消息后,将这批消息写入commitLog文件中,然后更新commitLog拉取偏移量,介者继续向主服务器拉取未同步消息
故障转移
Dledger集群搭建
0 条评论
下一页