乐趣区

关于rocketmq:RocketMqRocketMq-基本扫盲

jiezi

引言

本篇是 RocketMq 扫盲，并不会讲到各个组件实现的细节内容，这里从整体全局的角度看对于 RocketMq 的整体设计。

理论知识略显枯燥乏味，能够大抵理解一些基本概念之后，间接上手源代码以及参考官网文档理解各个组件的细节和设计思路，Rocket 各个子组件绝对比拟独立，能够拆分繁多子组件一一攻破。

一、根本介绍

一句话介绍 RocketMQ

RocketMQ 作为一款纯 java、分布式、队列模型的开源消息中间件，反对事务音讯、程序音讯、批量音讯、定时音讯、音讯回溯等支流音讯队列。

关键词

  1. 纯 JAVA 编写
  2. 分布式队列模型。
  3. 反对事务音讯、程序音讯、批量音讯、音讯回溯等等。
  4. 开源，为 Apach 基金会 顶级我的项目之一。

二、RocketMQ 常见问题

这些常见问题贯通整个音讯队列的学习，不同的音讯队列有不同的解决方案，须要进行横向和纵向比照。

  1. Broker 是如何进行分片存储的?
  2. Broker 的内部消息如何实现主从同步？
  3. RocketMq 如何确保 MessageId 唯一性？
  4. 百万音讯沉积的低提早如何做到的？
  5. RocketMQ 如何保障音讯不失落？
  6. 如何放弃音讯的程序生产？
  7. 如何避免音讯反复生产问题？

三、什么是音讯队列

In computer science, message queues and mailboxes are software-engineering
components typically used for inter-process communication (IPC), or for inter-thread
communication within the same process. They use a queue for messaging – the passing of
control or of content. Group communication systems provide similar kinds of functionality.

在计算机科学类畛域，音讯队列和邮箱都是软件工程组件，通常用于计算机外部同一过程或者同一过程的线程内通信（IPC），它们通过队列来传输管制信息或者内容，群组通信提供相似性能。

上面是来自 《数据密集型利用零碎设计》 第四章的局部介绍内容。

音讯队列最早是由一些商用免费软件管制，后续随着呈现各种开源软件 kafka、activeMQ、HornetQ、RabbitMQ 等风行，音讯队列逐步走进互联网的视线。

和 RPC 异步通信比照，音讯队列有上面几个特点：

  • 音讯队列能够充当缓冲关照单方的解决能力。
  • 防止发送方须要晓得接管方 IP 和地址的问题。
  • 反对一个音讯发给多个接管方。
  • 逻辑上的发送方和接管方拆散。

简略来说 音讯队列就是应用队列来通信的组件，在最后的定义外面，它仅仅用用于双端通信，然而并没有非凡的规定和要求。

然而到了当初，音讯队列更多指消息中间件，而消息中间件并不只有音讯队列，同时音讯队列自身的职责也在逐步简单和变动。

3.1 为什么须要音讯队列

很简略，因为传统的 WEB 架构对于几百的用户量根本入不敷出，然而一旦上万、上千万、上亿的时候，就必须要借助音讯队列来帮忙零碎解耦，音讯队列是重要的高并发和高可用组件。

你也能够简略的了解音讯队列就是抗 ” 揍 ” 的。

3.1.1 异步解决（异步）

异步这个概念其实很早就呈现了，异步解决通常用于实现须要疾速响应同时须要解决重要业务的状况，比方购物之后用户想早点看到付款后果，这时候就外部零碎可能须要调用商户服务，用户服务，订单服务，积分服务、结算服务配合。

这些业务会造成造成一条很长的链路，不可能等到业务全副实现才对客户响应，客户仅仅想要看到的是本人的购物是否胜利。

音讯队列异步解决的次要作用是缩小业务申请申请阻塞，进步业务解决能力的同时做到疾速的响应，业务零碎能够更加专一业务自身，同时利用队列实现不同业务的“转接”解决。

3.1.2 服务解耦（解耦）

实现服务解耦指的是 申请和接管方能够是两个齐全独立的零碎，通常音讯队列是作为不同服务之间信息传递的桥梁。

3.1.3 流量管制（削锋）

传统的 WEB 服务实际上抗压能力比拟弱，因为这些服务不仅须要承受参数，还须要解决大量的业务，这期间须要操作大量的表和数据，速度天然就会慢下来。音讯队列剥来到这一层，通过负载平衡的伎俩进行流量管制，同时提供多种生产模式进行抗压，这些都是传统 WEB 服务所不具备的个性。

哪怕 SQL 写的十分完满，数据处理究竟须要工夫，流量激增的状况下音讯队列是一种很重要的保命组件。

留神音讯队列自身也是双刃剑，尽管加一层能够解决软件架构难题，然而也造成零碎的复杂性，所以须要衡量业务和技术的变动进行抉择，而不是为了高性能枯燥的引入。

3.2 音讯队列毛病

多了一个队列，天然也就多了更多有可能产生的问题，音讯队列也是双刃剑，存在上面一些隐患：

  • 反复生产：比方某些扣款业务或者结算业务，反复生产某一个音讯是非常危险的。
  • 程序生产：有些场景必须要程序生产，比方扣款之后须要将钱转移到两头账户，此时须要将未实现的交易金额进行解冻，如果这个解冻呈现在付款之前，而付款出现异常，那么等于说是用户平白无故被冻了一笔钱，也是无奈承受的，所以生产程序十分重要。
  • 分布式事务：单体服务通常只须要用框架的注解即可实现事务一致性，而音讯队列个别用在微服务的分布式环境当中，如果一个零碎的音讯推送到另一个零碎，须要保障分布式事务统一，则会引入更多的复杂度。
  • 音讯沉积：如果消费者无奈及时的解决音讯，此时就会呈现音讯沉积，音讯沉积带来是消费者的长时间无奈响应，以及业务阻塞。

四、RocketMq 概览

4.1 次要特点

  • 天生反对公布 / 订阅模式和点对点（P2P）模型。
  • 百万音讯沉积甚至亿万音讯沉积的反对，并且能够维持写入低提早。

  • 反对 PULL 和 PUSH 两种推送模式。PULL 代表了消费者被动从 Broker 中拉取音讯，而 PUSH 指的是 MQ 给消费者推音讯，然而实际上 PUSH 是依赖 PULL 实现的。

    实现的形式：先从业务代码从一个 MQ 中 PULL 音讯，而后通过业务代码 PUSH 给特定的消费者。所以实际上是通过两头者通过两次 PULL 实现这一我的项目操作的。

  • 兼容多种音讯协定，比方 JMS 和 MQTT。
  • 提供 Docker 镜像治理测试和星散群部署。
  • 自带配置、指标、监控等功能丰富的 DashBoard。
  • 分布式以及高可用架构，满足至多以此消息传递语义。（RocketMQ 原生就是反对分布式的，而 ActiveMQ 原生存在单点性）。

4.2 队列模型抉择

队列模型的次要目标是决定消费者的生产逻辑和数据结构设计。在不同的中间件中不同的队列模型会间接影响数据结构和框架设计。

队列模型抉择分为 传统队列模型 和公布 / 订阅模型 ，以当初的支流中间件应用来看， 公布 / 订阅模型 更胜一筹。

4.2.1 传统队列模型

传统队列模型是遵循生产者消费者模式，这种模式就像是咱们日常生活中的抢票，谁抢到就是谁的，所以有可能一个人抢到很多张票，有的齐全没有票的状况。

这里间接偷了图拿来介绍了，队列能够存储多个生产者音讯，然而消费者存在竞争，同一时间每一条音讯只能是一个消费者生产。

4.2.2 公布 / 订阅模型

在设计模式的畛域的公布订阅的模式换个说法，其实就是指观察者模式，在音讯队列当中是非常重要的队列模型设计。

公布订阅模型 它能够解决一个音讯被多个消费者生产的问题，次要的解决流程把音讯封装到 Topic 当中，所有订阅了这个 Topic 的消费者才能够参加生产。

公布订阅模型在生活中非常常见，比方 QQ、微信的群聊。公布订阅模型反对同一条音讯被多个消费者生产的播送模式，也反对负载平衡的生产模式。

4.2.3 支流音讯队列抉择

目前支流音讯队列次要抉择如下：

  • kafka和 rocketmq：应用 公布订阅模式，设计模式也叫“观察者模式”。
  • RabbitMq和ActiveMq：应用了传统队列模型，或者说抢车票。

4.3 主题模型

RocketMq 的主题模型是公布订阅模型，那么公布订阅模型应用的是“观察者模式”，观察者模式过来集体写过一篇文章：

考古链接：# 浅谈设计模式 – 观察者模式（四）

这里简略回顾一下文中的案例，观察者模型就相似于咱们去平台买基金，一支基金可能会有多个关注者，一个关注者也能够关注多支基金变动。

当股市收盘的时候，基金的变动能够被所有人看到直到当天股市闭市场，这时候要么“天台蹦迪”，要么“今晚开酒”。

4.4 音讯模型

音讯模型可能要比后面几个略微简单一点，咱们须要理清 音讯、队列、主题 这三个主体之间的关系。

三者的关系大抵是一个嵌套关系，音讯往队列进行推送，而一个主题下能够有多个队列承受音讯，这里画一个图来进行了解：

在 RocketMq 的公布订阅模型中，咱们所说的音讯是不能凭空存在的，它必须存储在某个 Queue 当中，Queue 和日常咱们了解的队列没有区别，一条音讯就是 Queue 外面的一个成员，Queue 自身也不是独自存在，而是寄存于一个 Topic 当中，也就是咱们所说的主题。

为什么要设计这么麻烦，生产者构建音讯发给消费者不行么？

答案是的确能够，不过会性能过于羸弱了，能够设想一下这样一来的音讯发送就相似短信轰炸，消费者不晓得本人要什么音讯，只晓得会有生产者发给它，生产者也不晓得要发给哪个消费者生产，所以它的音讯会一股脑全给消费者，消费者还须要额定编写一大堆逻辑从中挑取须要的音讯。

如果是一对一传话，这种传信倒是很不便，因为你晓得我要啥，我也晓得你发的啥。然而一旦超过多个对象相互传信，这样的会造成重大的高耦合和构造凌乱，也不合乎音讯队列高性能，简略架构的特点。

此外，一个主题下应用多个队列能够进步并发性能，最直观的比喻就是核酸队伍排队的时候，四个通道的总是要比一个通道的效率高十分多。

是不是感觉画面来了。

理论的业务部署中，消费者和生产者会组成集群，集群以消费者组和生产者组的形式存在。

生产者组和消费者组的具体概念咱们别离放到组件进行介绍，这里只有明确他们是生产者和消费者构建的集群即可。

生产位点

生产位点的性能是对于生产进度进行跟踪，因为消费者队列中的内容有可能被多个消费者生产，所以必须要晓得每个消费者的生产进度，同时生产位点也能够使得被生产的内容不会反复生产。

4.2 根底运行流程

次要的运行流程如下：

  1. NameServer 启动，Broker 进行服务注册，NameServer 须要注册所有的 Broker。
  2. 服务发现，连贯所有的生产者和消费者，并且定时进行心跳包发送。
  3. 生产者发送音讯之前从 NameServer 获取 Broker 的注册列表，依据负载平衡算法选出其中一台 Broker 进行音讯推送。
  4. Namever 和 Broker 放弃长连贯，同时每 30S 进行一次心跳检测，如果检测到超过 120S 没有响应（心跳检测机制），从路由表将其删除。
  5. 消费者订阅某个主题前，须要先从 NameSever 查找对应的 Broker 列表（或者某个集群），从 Broker 当中订阅音讯进行生产，同时由 Broker 指定订阅规定。

4.3 相干术语

4.4.1 音讯

音讯是数据传输的载体，也是生产和消费者生产的最小单位，音讯必须要属于一个主题，每个音讯领有惟一的 Message ID，能够携带具备业务标识的 Key，零碎提供了 Message ID 以及 Key 进行查问的性能。

4.4.2 标签

标签相似子菜单，是对于音讯的进一步划分，次要是用于用户辨别音讯的业务标识，比方同一类标签的音讯放到一起进行生产，比方有一个订单的 Topic，能够划分出订单交易胜利 Tag 音讯、订单失败 Tag 音讯、订单手续费 Tag 音讯等，也就是说同一个 Topic 能够划分出不同的 Tag 的音讯，做出更细化的音讯管制。

总之，标签能够 简略看作是音讯的“Category”。

4.4.3 主题

示意一类音讯的汇合，每个主题蕴含若干条音讯，每条音讯只能属于一个主题，是 RocketMQ 进行音讯订阅的根本单位。

主题能够单纯的看作一个队列，生产者所生产的音讯是无奈发送的，须要推送到主题这个队列当中能力通过 Broker 发送给消费者进行生产。

五、RocketMq 设计理念

5.1 集群部署

能够发现次要的模块都能够进行集群部署，所以咱们能够对于 Producer、Consumer、Broker、NameServer 四个模块进行集群解决，用一张图示意。

这里同样偷了张图介绍根本的架构模式：

留神这里根本合乎一个简略的理论业务部署模式，每个组件构建集群的同时，Broker 集群还设置了 Master-Slave 主从节点实现高可用。

简略介绍

这里介绍各个角色的职责。

Producer：

音讯生产者，能够集群部署。推送音讯首先须要和 NameServer 任意一台进行长连贯，依据路由算法找到 Topic 理论存储在哪一台 Broker Master 下面，而后再和 Broker 进行长连贯发消息，生产者反对同步和异步的形式发送音讯信息。

Consumer：

音讯消费者，也能够集群部署。同样须要和 NameServer 进行长连贯，而后通过路由算法找到 Broker，找到对应的 Master 或者 Slave，而后和 Broker 建设长连贯并，消费者反对集群生产和播送生产。依据生产模型，还能够进行程序生产和并发生产。

Broker：

音讯的理论存储媒介，须要连贯 NameServer 以提供路由信息，Producer 在发送音讯之前须要通过 NameServer 找到 Broker 推送音讯，Consumer 同样须要按此操作找到 Broker，而后才可能生产音讯。

NameSever：

轻量级无状态设计，次要负责为整个音讯队列提供路由服务以及 Broker 治理，相互之间能够构建集群，然而 NameSever 并不间接通信，而是 ** 独立部署服务 **。NameSever 是为了代替 Zookeeper 强一致性的的存在。

各个组件的细节这里拆分到 [[01d – RocketMq 基础架构详解]] 外面进行解释。

集群作用

如果把这些角色组成集群，那么各个集群又能够划分上面的性能：

Consumer：

反对 Push 和 Pull 两种生产模式，反对集群生产和播送生产。

Producer：

反对以多种负载平衡的模式向 Broker 发送音讯。

NameSever：

须要独立服务部署，然而不障碍节点相互通信形成集群。NameSever 能够看作是轻量级的单体服务，次要的性能如下：
  • 治理 Broker 集群，定期发送心跳包检测 Broker 是否存在。
  • 为生产者和消费者以及 Broker 进行路由治理。

Broker：

负责 Topic 和 Queue 的音讯存储，反对推和拉两种模式。提供上亿级别的音讯程序音讯沉积。此外提供可视化治理平台，这些都是特有性能。

Broker 相比其余模块要简单不少，次要分为上面的内容：

  • 近程解决模块。Broker 入口，解决客户端信息。
  • 客户端治理，治理客户端性能，保护消费者和主题订阅。
  • HA 服务，提供主从 Broker 间数据同步。
  • 索引服务，应用健作为索引构建索引。
  • 存储服务，提供在物理硬盘上存储和查问音讯的简略 API。

5.2 事务音讯

上面是官网原话：

事务音讯是指利用本地事务和发送音讯操作能够被定义到全局事务中。相似 X/Open XA 的散布事务性能，通过事务音讯能达到 分布式事务的最终统一。

大家不要被这句话骗了，这句话的意思是事务音讯不提供分布式事务的完满解决方案，我提供相似的事务性能，然而只能保障 最终数据一致性 ，只是针对音讯发送和数据落库的保障， 留神 RocketMq 通常的做法是先执行本地事务后发送音讯。

然而 Rocket 事务音讯存在比拟多的缺点，比方只反对单事务，再比方模板代码迁徙麻烦等状况，也和咱们设想的“Spring 事务”不太一样，这一点后续文章会具体介绍。

5.3 定时音讯

定时音讯（提早队列）是指音讯发送到 broker 后，不会立刻被生产，期待特定工夫投递给真正的 Topic。

目前版本的 RocketMq 并没有实现准确的工夫管制，目前反对的提早级别如下：

默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18 个 level。能够配置自定义 messageDelayLevel。

private String messageDelayLevel = "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h";

5.4 音讯过滤

音讯过滤指的是能够在某些条件下对于 Topic 的音讯进行过滤，也叫做条件生产。

音讯过滤是通过 Tag 实现的，基于音讯属性过滤须要 SQL92 表达式实现。此外音讯过滤能够产生在消费者和 Broker 两处：

  • Broker 音讯过滤：如果是 Broker 过滤，则从源头过滤出消费者须要的音讯。
  • 消费者过滤：更像是权限管制，只将满足条件的音讯放行，然而不妨碍其余音讯进入。

5.5 高效 IO

因为 Rocket 会对于音讯进行长久化，谋求高吞吐量同时须要保障高效 IO。高效 IO 靠的是上面几个组件：

  • 索引文件
  • CommitLog
  • 索引偏移列表

RocketMq应用了文件组的概念，为了实现磁盘对齐，保障每一个文件大小固定，同时引入了内存映射机制辅助。所有的音讯都是基于程序写，同时为了高效查问与高效生产，还引入了索引文件的概念。

高效 IO的另一个体现是在日志中应用 追加写入代替批改和删除，这个设计集体猜测是借鉴了 Lsm-Tree 的设计思路。具体能够看看[[《数据密集型型零碎设计》LSM-Tree VS BTree]]

5.6 不完满设计

所谓不完满设计的关键点：Rocket 只保障音讯必须至多生产一次，然而不保障反复生产不会呈现，也就是说设计上自身就是存在反复生产的。所以要防止反复生产，须要客户端本人通过各种形式躲避反复生产问题。

5.7 去 ZK

RocketMq 晚期和 Kafka 一样依赖 Zookeeper 实现强一致性，然而随着版本迭代，很快开发出轻量级的 NameSever 代替 Zookeeper，摒弃了路由信息的强一致性，转而实现了在分钟级别上面的强一致性（30S 心跳检测），并且实现了数据的最终一致性特征性。

简化设计和去中间件带来的是运维难度的缩小，和架构的实现简洁。

5.8 音讯模型（Message Model）

  • 次要分成三局部：Producer、Consumer、Broker。对应性能是生产者、消费者、存储音讯。
  • Broker 理论部署对应一台服务器，Broker 能够存储多个 Topic 音讯。
  • 每个 Topic 也能够分片存储在不同的 Broker。
  • Message Queue 用于存储音讯物理地址。
  • 每个 Topic 的音讯地址存储在多个 Message Queue 当中。
  • ConsumerGroup 由多个实例形成。

Rocket 提供了多种生产模型，并发生产 和程序生产。

5.81 并发生产

对于一个队列的音讯，每一个消费者都会创立一个线程池对于音讯进行多线程解决，所以有可能偏移量大的音讯会比偏移量小的音讯先进行生产。

这里用进度条的例子做一个不是很失当的比喻，咱们加载视频的时候，没有看到的内容会当时缓存，有时候就会往后的地位要比往前的地位更早加载的状况。

5.8.2 程序生产

RocketMq 尽管能够做到程序生产，然而须要留神它所保障的是 同一个分区的程序生产，如果要保障整个全局的程序生产统一，须要把所有的音讯发往一个分区，因为每一个分区能够看作是 FIFO 队列。

理论应用是全局指定同一个 Topic，而后为业务分类不同的标签 Tag，也就是实现了全局生产统一的问题，然而这种一致性通常在业务量不大的状况下能够这么玩。

某些场景下必须要进行程序生产，比方 Mysql Bin 文件复原的场景，这时候音讯须要依照 y 严格程序 进行生产，然而代价是集群变单机，并且一个节点不可用导致整个节点不可用。

所以 RocketMQ 在实现中提供了基于 FIFO 队列的程序生产模型，尽管每一个消费者仍然会创立一个多线程，然而队列会通过加锁的形式实现同步生产。

留神在生产模型中并发生产总共会进行 16 次重试，并且每一次重试的工夫会逐步拉长。而程序生产在生产某一个音讯的时候，如果生产失败，会始终进行反复生产。显然程序生产在应用的时候须要进行异样辨别，比方辨别是业务异样，零碎异样，如果不是业务异样，则重试多少次都是没有意义的。这时候须要提供额定的报警机制。

5.8.3 生产进度

消费者进行生产的时候，采纳的是相似进度条的偏移点位标记形式，相似咱们视频看到一半的时候，下次关上回到上一次关上的地位，持续实现后续的操作。

在 RocketMq 当中实现生产进度的前提是 生产组，生产点位存储在生产组中。

单体消费者不须要生产进度的加持，拿到间接生产即可。

如果是 集群模式，音讯存储在 Broker，生产进度存储在${ROCKETMQ_HOME}/store/config/consumerOffset.json。这个门路通过 BrokerHelper 工具帮忙类进行治理。

而如果是 播送模式，生产进度文件存储在用户的主目录，默认文件路径名：${USER_HOME}/.rocketmq_offsets。

官网也有相干阐明，留神在文件后面的点号：

默认状况下，offsets.json 文件在 /home/{user}/.rocketmq_offsets 中

5.9 重要降级

5.9.1 多正本（4.5.0）

客户端在 4.5.0 当中有一个重要降级，多正本概念，所谓的多正本概念指的是。

降级阐明：Release Notes – Apache RocketMQ – Version 4.5.0 – Apache RocketMQ

ISSUE：[ISSUE-1046]- Support multiple replicas for RocketMQ.

GIthub 原始链接：Add store with dledger by dongeforever · Pull Request #1046 · apache/rocketmq (github.com)

简要阐明：

实现基于 raft 的代理，指的是一个复制组（Master-Slave）能够演变为给予 Raft 协定的复制组，复制组内的应用 Raft 协定放弃节点数据强一致性，次要用于金融对于数据强一致性的场景。

5.9.2 主动主从切换（5.0）

RocketMq 5.0 反对了主动的主从切换，具体能够浏览Deployment.md（RocketMQ 5.0 主动主从切换）局部进行理解。

次要减少反对主动主从切换的 Controller 组件，Controller 组件能够独立部署也能够内嵌在 NameServer 中。

  • 设计思路：docs/cn/controller/design.md
  • 主动主从切换疾速开始：docs/cn/controller/quick_start.md
  • 部署和降级：docs/cn/controller/deploy.md

5.10 负载平衡

Rocket 负载平衡的计划有比拟多的形式，然而罕用的就两种，这里举一个参考案例进行介绍。

以集群模式的部署为例，消费者是如何调配音讯的？

假如某个 Topic 有 16 个队列，此时有 3 个消费者的生产组来负责调配这些队列，把队列依照 0 – 15 进行排列，组成 q0 – q15，消费者则用 c0 – c2 示意。

首先须要明确一点：同一个消费者同一时间能够被安顿到多个队列，然而同一时间只能是一个消费者生产某一条音讯。

艰深了解就是进地铁站的时候闸机有很多个，然而最终只能进到一个闸机中刷卡进站或者出站。

RocketMq 有很多队列调配算法，最终罕用的上面两个：

  • AllocateMessageQueueAveragely：平均分配
  • AllocateMessageQueueAveragelyByCircle：轮流平均分配

如果是 AllocateMessageQueueAveragely 算法，则 q0-q15 依照上面的形式划分：

  • c0：q1 – q5、q16
  • c1：q7 – q10
  • c2：q11 – q15

这种调配也就是简略的除法，如果 碰到余数，则接着桉程序进行调配，比方这里的 q16 分到了 c0。

依据轮流调配 算法AllocateMessageQueueAveragelyByCircle 进行均匀分类则更像是把斗地主轮流摸牌一样，也就是 c0=>q1，c1=>q2，c2=>q3，c0=>q4，c1=>q5 这样的形式进行解决。

六、小结

Rocket 根本扫盲篇，次要介绍了上面几点内容：

  • 什么是音讯队列，音讯队列的定义以及优劣比照。
  • 什么是 RocketMQ，RocketMq 的根底概念，以及根底术语介绍。
  • RocketMQ 的一些重要设计理念，以及局部重要降级内容。
  • RcoketMq 音讯模型，并发和程序生产，以及生产进度的解释。
  • 一些 FAQ 和常见的音讯队列问题。

以上为集体对于 RocketMq 的扫盲篇整顿，文章无奈做到八面玲珑，更多内容能够参考官网文档理解更多细节。

N、FAQ

 1. 如何了解 Rocketmq 中 Topic、Queue 以及偏移量呢？

Topic 是一个逻辑汇合，具备某种业务上共性的性质的音讯会发到指定的 Topic 中，须要取对应性质的音讯也会到指定 Topic 中取，如被测我的项目中的 Running top、Finish top 等。

要了解 Queue，首先要晓得负载平衡这个概念，如果集群中有两个 consumer，那我 queue 的应该是 2 的倍数，这样能够放弃负载平衡。

要了解偏移量就须要晓得 mq 程序写随机读的一个概念，mq 的音讯实际上是从 pagecache 长久化到磁盘文件：commitlog 中，程序写入，因而 consumer 中读取的时候须要晓得从哪里读，也就是通过偏移量来标识。

2. 生产者、消费者与 Topic 主题之间的关系？

生产者、消费者与 Topic 主题之间的关系是，一个 Topic 能够由多个生产者发送音讯，反过来一个生产者也能够发送多个 Topic 音讯。一个 Topic 能够由多个消费者生产，消费者能够生产多个 Topic 音讯。

3. 为什么抉择 RocketMQ 作为你们我的项目中的消息中间件？

能够从上面几点进行答复：

  1. RocketMQ 集群无单点，可扩大，任意一点高可用，程度可扩大；
  2. 反对海量音讯沉积能力，音讯沉积后，写入低提早；
  3. 反对上万个队列（与 ActiveMQ 进行比照）；
  4. 反对音讯失败重试机制；
  5. 音讯可查问；
  6. 开源社区沉闷；
  7. 成熟度（通过双十一考验）；

4. 为什么要有 NameServer?

纵观整个 RocketMq 的组件，你会发现如同 NameServer 也没啥用呀，不就一个路由治理和 Broker 心跳检测性能么，为什么要多出一层？

实际上 NameServer 是十分奇妙的解耦设计，如果所有的 Broker 和生产者以及消费者连贯，那么自身的职责就会变得十分复杂，也不好保护和负载平衡。

NameServer 就像是微服务中的注册核心，如果其余组件要找到对方，就须要“指路人”的帮忙，RocketMq 利用 NameServer 把这一部分职责抽取进去是十分理智的。

其次 NameServer 自身就是为了取代 ZK 存在的，有了 NameServer 不须要其余中间件的烦扰，缩小了运维的复杂性，并且有更高的性能和灵活性。

参考文章

RocketMQ 介绍及基本概念_fFee-ops 的博客 -CSDN 博客_rocketmq

官网文档

退出移动版