没有合适的资源?快使用搜索试试~ 我知道了~
手写RocketMq详细操作手册
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
5星 · 超过95%的资源 1 下载量 165 浏览量
2022-12-10
13:36:52
上传
评论
收藏 3.8MB PDF 举报
温馨提示
试读
84页
RocketMq操作手册:针对入门初中级别。 消息队列 RocketMQ 是阿里巴巴集团基于高可用分布式集群技术,自主研发的云正式商用的专业消息中间件,既可为分布式应用系统提供异步解耦 和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性,是阿里巴巴双 11 使用的核心产品。 RocketMQ 的设计基于主题的发布与订阅模式,其核心功能包括消息发送、消息存储(Broker)、消息消费,整体设计追求简单与性能第一。 1. NameServer 设计及其简单,RocketMQ 摈弃了业界常用的 Zookeeper 充当消息管理的“注册中心”,而是使用自主研发的 NameServer 来实现各 种元数据的管理(Topic 路由信息等) 2. 高效的 I/O 存储,RocketMQ 追求消息发送的高吞吐量,RocketMQ 的消息存储设计成文件组的概念,组内单个文件固定大小,引入了内存映射机 制,所有主题的消息存储基于顺序读写,极大提高消息写性能,同时为了兼顾消息消费与消息查找,引入消息消费队列文件与索引文件
资源推荐
资源详情
资源评论
RocketMQ 介绍
消息队列 RocketMQ 是阿里巴巴集团基于高可用分布式集群技术,自主研发的云正式商用的专业消息中间件,既可为分布式应用系统提供异步解耦
和削峰填谷的能力,同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性,是阿里巴巴双 11 使用的核心产品。
RocketMQ
的设计基于主题的发布与订阅模式,其核心功能包括消息发送、消息存储
(Broker)
、消息消费,整体设计追求简单与性能第一。
1. NameServer
设计及其简单,
RocketMQ
摈弃了业界常用的
Zookeeper
充当消息管理的“注册中心”,而是使用自主研发的
NameServer
来实现各
种元数据的管理(
Topic
路由信息等)
2.
高效的
I/O
存储,
RocketMQ
追求消息发送的高吞吐量,
RocketMQ
的消息存储设计成文件组的概念,组内单个文件固定大小,引入了内存映射机
制,所有主题的消息存储基于顺序读写,极大提高消息写性能,同时为了兼顾消息消费与消息查找,引入消息消费队列文件与索引文件
3.
容忍存在设计缺陷,适当将某些工作下放给
RocketMQ
的使用者,比如消息只消费一次,这样极大的简化了消息中间件的内核,使得
RocketMQ
的实现发送变得非常简单与高效。
RocketMQ 原先阿里巴巴内部使用,与 2017 年提交到 Apache 基金会成为 Apache 基金会的顶级开源项目,GitHub 代码库链
接:https://github.com/apache/rocketmq.git
RocketMQ
的官网
http://rocketmq.apache.org/
MQ:消息中间件是什么?
消息中间件属于分布式系统中一个子系统,关注于数据的发送和接收,利用高效可靠的异步消息传递机制对分布式系统中的其余各个子系统进行集成
核心概念
NameServer
NameServer
是整个
RocketMQ
的“大脑”,它是
RocketMQ
的服务注册中心
,
所以
RocketMQ
需要先启动
NameServer
再启动
Rocket
中的
Broker
。
Broker 在启动时向所有 NameServer 注册(主要是服务器地址等),生产者在发送消息之前先从 NameServer 获取 Broker 服务器地址列表(消费者一
样),然后根据负载均衡算法从列表中选择一台服务器进行消息发送。
NameServer
与每台
Broker
服务保持长连接,并间隔
30S
检查
Broker
是否存活,如果检测到
Broker
宕机,则从路由注册表中将其移除。这样就可以实
现
RocketMQ
的高可用。具体细节后续的课程会进行讲解。
主题
主题,
Topic
,消息主题,一级消息类型,生产者向其发送消息。消费者负责从
Topic
接收并消费消息。
生产者
生产者:也称为消息发布者,负责生产并发送消息至 Topic。
消费者
消费者:也称为消息订阅者,负责从
Topic
接收并消费消息。
消息
消息:生产者或消费者进行消息发送或消费的主题,对于
RocketMQ
来说,消息就是字节数组。
核心概念
以下我们将总结下 Rocket 的整体运转。
1. NameServer
先启动
2. Broker
启动时向
NameServer
注册
3.
生产者在发送某个主题的消息之前先从
NamerServer
获取
Broker
服务器地址列表(有可能是集群),然后根据负载均衡算法从列表中选择一台
Broker
进行消息发送。
4. NameServer 与每台 Broker 服务器保持长连接,并间隔 30S 检测 Broker 是否存活,如果检测到 Broker 宕机(使用心跳机制,如果检测超过
120S),则从路由注册表中将其移除。
5. 消费者在订阅某个主题的消息之前从 NamerServer 获取 Broker 服务器地址列表(有可能是集群),但是消费者选择从 Broker 中 订阅消息,订阅
规则由 Broker 配置决定。
RocketMQ 的设计理念和目标
设计理念
整体设计思想
80%
借鉴
Kafka.
基于主题的发布和订阅,其核心功能,消息发送、消息存储和消息消费。整体设计追求简单与性能。
NameServer
性能对比
Zookeeper
有极大的提升
高效的
IO
存储机制,基于文件顺序读写,内存映射机制
容忍设计缺陷,比如消息只消费一次,Rocket 自身不保证,从而简化 Rocket 的内核使得 Rocket 简单与高效,这个问题交给消费者去实现(幂等)。
设计目标
架构模式:发布订阅模式,主要组件:消息发送者、消息服务器(消息存储)、消息消费、路由发现。
顺序消息:
RocketMQ
可以严格保证消息有序
消息过滤:消息消费是,消费者可以对同一主题下的消息按照规则只消费自己感兴趣的消息,可以支持在服务端与消费端的消息过滤机制。
消息存储:一般
MQ
核心就是消息的存储,对存储一般来说两个维度
:
消息堆积能力和消息存储性能。
RocketMQ
追求消息存储的高性能,引入内存映
射机制,所有的主题消息顺序存储在同一个文件中。同时为了防止无限堆积,引入消息文件过期机制和文件存储空间报警机制。
消息高可用:
1. Rocket 关机、断电等情况下,Rokcet 可以确保不丢失消息(同步刷盘机制不丢失,异步刷盘会丢失少量)。
2. 另外如果 Rocket 服务器因为 CPU、内存、主板、磁盘等关键设备损坏导致无法开机,这个属于单点故障,该节点上的消息全部丢失,如果开启了
异步复制机制,Rocket 可以确保只丢失很少量消息。
3. 如果引入双写机制,这样基本上可以满足消息可靠性要求极高的场景(毕竟两台主服务器同时故障的可能性还是非常小)
消息消费低延迟:
RocketMQ
在消息不发生消息堆积时,以长轮询模式实现准实时的消息推送模式。
确保消息必须被消费一次:消息确认机制
(ACK)
来确保消息至少被消费一次,一般
ACK
机制只能做到消息只被消费一次,有重复消费的可能。
消息回溯:已经消费完的消息,可以根据业务要求重新消费消息。
消息堆积:消息中间件的主要功能是异步解耦,还有个重要功能是挡住前端的数据洪峰,保证后端系统的稳定性,这就要求消息中间件具有一定的
消息堆积能力,
RocketMQ
采用磁盘文件存储,所以堆积能力比较强,同时提供文件过期删除机制。
定时消息:定时消息,定时消息是指消息发送到
Rocket Broker
上之后,不被消费者理解消费,要到等待一定的时间才能进行消费,
apache
的版本目
前只支持等待指定的时间才能被消费,不支持任意精度的定时消息消费。(一个说法是任意精度的定时消息会带来性能损耗,但是阿里云版本的
RocketMQ
却提供这样的功能,充值收费优先策略?)
消息重试机制:消息重试是指在消息消费时,如果发送异常,那么消息中间件需要支持消息重新投递,RocketMQ 支持消息重试机制。
RocketMq 中消息的发送
普通消息是指消息队列 RocketMQ 中无特性的消息,区别于有特性的定时/延时消息、顺序消息和事务消息。这些后续会细讲。
RocketMQ
发送普通消息有三种实现方式:单向
(OneWay)
发送、可靠同步发送、可靠异步发送。
消息生产的客户端依赖如下:
剩余83页未读,继续阅读
资源评论
- qikunpeng2023-01-11感谢资源主的分享,这个资源对我来说很有用,内容描述详尽,值得借鉴。
小杨互联网
- 粉丝: 2w+
- 资源: 187
下载权益
C知道特权
VIP文章
课程特权
开通VIP
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功