关于mq:消息中间件基础知识

by zhimaxingzhe from 消息中间件基础知识 欢送分享链接，转载请注明出处，尊重版权，若急用请分割受权。https://zhimaxingzhe.github.io

前言

本文梳理笔者的 MQ 常识，从消息中间件的基础知识讲起，在有了基础知识后，对市面上各支流的消息中间件进行具体的解析，包含 RabbitMQ、RocketMQ、Kafka、Pulsar，最初再横向比照这几款支流的消息中间件。

介绍 MQ 的文章网上千千万，最好的学习路径还是官网文档，文中介绍的这几款 MQ 都在致力推广本人，所以文档在权威性、全面性、专业性、时效性都是无人能及其左右，当初的官网文档甚至本人做竞品比对，比方 RocketMQ 就本人放了比对表格在首页。所以要学好哪一款 MQ，就去看它的官网吧，地址放在文末参考资料中了。

最好的学习办法是带着问题去寻找答案，以费曼学习法为规范，产出可教学的材料，所以本文多是集体的所学梳理和所想记录，集体只是无限，不免有所疏漏，文中有谬误和疏漏请不吝赐教，感激🫶！若有帮忙，请一键三连吧🤝。文中许多图片内容是随笔摘抄，若有触犯，侵删🤝。

消息中间件的倒退曾经有近 40 年历史，早在上个世纪 80 年代就诞生了第一款音讯队列 The Information Bus。

到 90 年代 IBM、Oracle、Microsoft 纷纷推出自家的 MQ，但都是免费且闭源的产品，次要面向高端的企业用户，这些 MQ 个别都采纳高端硬件，软硬件一体机交付，须要洽购专门的保护服务，MQ 自身的架构是单机的架构，用户的自主性较差。

进入新世纪后，随着技术成熟，人们开始探讨 MQ 的协定，诞生了 JMS、AMPQ 两大协定规范，随之别离有 ActiveMQ、RabbitMQ 的具体实现，并且是开源共建的，这使得这两款 MQ 在过后迅速风行开来，MQ 的应用门槛也随之升高，越来越多零碎融入了 MQ 作为根底能力。

再起初 PC 互联网、挪动互联网的爆发式倒退，因为传统的音讯队列无奈接受亿级用户的拜访流量和海量数据传输，诞生了互联网消息中间件，外围能力是全面采纳分布式架构、具备很强的横向扩大能力，开源典型代表有 Kafka、RocketMQ、Pulsar。Kafka 的诞生还将消息中间件从 Messaging 畛域延长到了 Streaming 畛域，从分布式应用的异步解耦场景延长到大数据畛域的流存储和流计算场景。Pulsar 更是在 Kafka 之后集大家之成，在企业级利用上做得更好，存储和计算拆散的设计使得拓展更加轻松。

现在，IoT、云计算、云原生引领了新的技术趋势。面向 IoT 的场景，音讯队列开始从云内服务端利用通信，延长到边缘机房和物联网终端设备，反对 MQTT 等物联网标准协议也成了各大音讯队列的标配，咱们看到 Pulsar、Kafka、RocketMQ 都在致力追随时代步调，拓展本人在各种应用场景下的能力。

1、消息中间件的定义

在早些年 MQ 始终被叫做音讯队列，就能够定义为传递音讯的容器，随着时代的倒退，MQ 都在致力拓展进去越来越多的性能，越来越多需要加在 MQ 纸上，消息中间件的能力越来越强，利用的场景也越来越多，如果非要用一个定义来概括只能是形象进去一些概念，概括为跨服务之间传递信息的软件。

2、用处

异步解决

能够把接口申请依据业务的时效性水平，将不紧急的解决逻辑生成音讯、事件放到 MQ 当中，再由专门的零碎解决该音讯、事件；如日志上报、归档事件、数据推送、数据分析、触发策略、变更举荐、增加积分、发送告诉音讯等。

削峰填谷

作为零碎外部的一个音讯池，抵制洪峰，对后端服务起到爱护作用。流量洪峰进来的时候，会转换为音讯落到 MQ 当中，后端服务能够依据本人的解决能力来，流量不会间接冲击到后端服务，特地是落库、IO 等操作。

服务解耦

缩小零碎、模块之间间接对接带来的耦合，交互对立按 MQ 中音讯的协定，按需生产和生产，耦合水平大大降低。

公布订阅

零碎产生的行为不须要通过接口等形式来告诉到相干服务，只须要公布一次音讯，订阅者都能生产到音讯，执行服务本身的本职工作。

当然，所有收益都是有代价的，对于零碎架构自身来说，会引入新组件，带来零碎复杂度的晋升，整体零碎的可靠性也会是挑战，减少消息中间件的运维老本，还会带来整体零碎一致性的问题。所以须要衡量本身零碎是否有必要引入 MQ，能解决什么痛点，投入产出是否让组织称心，对于自身流量不大的零碎来说，放弃简略架构是大快人心的事件，毕竟，越简略越稳固，越耐用。

3、音讯模型

队列模型

一种是音讯队列，生产者往队列写音讯，消费者从这个队列生产音讯，当然生产者能够是多个，消费者也能够是多个，然而一条音讯只能被生产一次，具体怎么做的，这就波及到具体的应用需要和每一款消息中间件的实现了，前面第二局部的时候会波及到。这是最早的音讯模型，这也是为什么音讯队列 MQ 这个名字也始终有人在用吧。

订阅模型

起初上个世纪 80 年代有人提出公布订阅模式，就是 topic 模式，生产者公布的音讯，消息中间件会把音讯投递给每一个订阅者，这个投递的过程有可能是推也可能是拉，反对哪一种也要看每一款的具体实现。

4、音讯协定

从音讯的生命周期来看，音讯的生产、存储、生产的整个过程来标准步骤要达到的规范。比方金融级别的音讯协定会要求保障音讯生产过程中不丢、不反复，存储过程中也能有持久性、一致性的要求，在生产过程中保障音讯正确被生产，如不反复、不错位等。

常见的音讯协定：

接下来举例 AMPQ 协定的生产、生产过程规范。

AMQP 协定

高级音讯队列协定（Advanced Message Queuing Protocol），一个提供对立音讯服务的应用层规范高级音讯队列协定，是应用层协定的一个凋谢规范，为面向音讯的中间件设计。基于此协定的客户端与消息中间件可传递音讯，并不受客户端 / 中间件不同产品，不同的开发语言等条件的限度。

生产音讯

生产音讯

MQTT 协定

MQTT(音讯队列遥测传输)是 ISO 规范 (ISO/IEC PRF 20922) 下基于公布 / 订阅范式的音讯协定。它工作在 TCP/IP 协定族上，是为硬件性能低下的近程设施以及网络情况蹩脚的状况下而设计的公布 / 订阅型音讯协定。

MQTT 协定是轻量、简略、凋谢和易于实现的，这些特点使它适用范围十分宽泛。在很多状况下，包含受限的环境中，如：机器与机器（M2M）通信和物联网（IoT）。其在，通过卫星链路通信传感器、偶然拨号的医疗设施、智能家居、及一些小型化设施中已宽泛应用。

其余协定

另外还有 STOMP、OpenMessaging 等，这里不做开展。以后市面上支流的消息中间件多是有自定义的协定倒退起来的，如 Kafka 在最开始并不算是一个消息中间件，而是用于日志记录零碎的一部分，所以并不是基于某种中间件音讯协定来做的，而是基于 TCP/IP，依据自定义的音讯格局，来传递日志音讯，为满足对于音讯失落是有肯定容忍度的；在起初逐渐倒退到能够反对正好一次（Exactly Once）语义，实际上是通过 At Least Once + 幂等性 = Exactly Once。

将服务器的 ACK 设置为 -1，能够保障 Procedure 到 broker 不会失落数据即 At Least Once；绝对的，服务器级别设置为 0，能够保障生产者发送音讯只会发一次，即 At Most Once 语义然而，一些十分重要的音讯，如交易数据，上游消费者要求音讯不重不漏，即 Exactly Once，精准一次，在 0.11 版本之前，Kafka 是无能为力的，只能通过设置 ACK=-1，而后业务消费者本人去重。

0.11 版本之后，Kafka 引入了幂等性概念，procedure 无论向 broker 发送多少次音讯，broker 只会长久化一条：At Least Once + 幂等性 = Exactly Once。要启用幂等性，只须要将 procedure 参数中的 enable.idempotence 设置为 true 即可，Kafka 的幂等性实现其实就是将原来在上游做的去重放在了数据上游。开启幂等性的 procedure 在初始化的时候会调配一个 PID，发往同一个 partition 的音讯会带一个 Sequence Number，而 broker 端会对 <PID, Partition, SeqNumber> 做缓存，当雷同主键音讯提交时，broker 只会长久化一条。

基于这个了解咱们看下 Kafka 的音讯报文格式定义，
协定概要：

再开展看 Message 的定义：

基于 TCP/IP 协定，通过定义音讯格局，在申请和响应中做可靠性保障。且随着倒退在批改协定，比方 Timestamp 是为了减少工夫索引，在 0.10.0 版本后减少的，用于依据工夫戳疾速查找特定音讯的位移值，优化 Kafka 读取历史音讯迟缓的问题。

Streaming、Eventing 场景下目前还没有看到有公认音讯协定的呈现。

往下的篇幅将开展介绍 RabbitMQ、RocketMQ、Kafka、Pulsar 这四款支流消息中间件的基础知识。

5、RabbitMQ

基于 Erlang 语言开发实现，单机性能体现不错，横向拓展能力较弱，可用于吞吐量在万级的零碎当中。

音讯模式

RabbitMQ 反对简略模式、工作队列模式、公布 / 订阅模式、路由模式、主题模式和 RPC 模式。

<center> 简略模式 </center>

<center> 队列模式 </center>

<center> 公布订阅模式 </center>

<center> 路由模式 </center>

<center> 主题模式 </center>

<center>RPC 模式 </center>

以上所有模式实际上都及基于音讯队列来实现的，公布订阅模式和主体模式，也是通过队列来实现的，对交换器绑定后再通过路由规定来散发音讯到队列中，也就是 BindingKey 和 RoutingKey，因为 RoutingKey 不能反复，也就意味着队列收到的音讯不能一样，而每条音讯只会发送给订阅列表里的一个消费者，从而就是没有消费者组的概念，无奈做到真正的公布订阅。带着这个了解看 RabbitMQ 架构就会比拟清晰了。

RabbitMQ 架构

上图是单机的架构，那么集群架构是怎么样的呢？

HA-Proxy 一款提供高可用性、负载平衡以及基于 TCP 和 HTTP 利用的代理软件，次要是做负载平衡的 7 层，也能够做 4 层负载平衡。

Keepalived 是集群治理中保障集群高可用的一个服务软件，其性能相似于 heartbeat，用来避免单点故障。

尽管是高可用计划，但总体来说横向扩大能力较弱。

RabbitMQ 控制台的介绍查看官网文档，也能够查看 Part 3: The RabbitMQ Management Interface。

RabbitMQ 就介绍到这里，更多信息可查看官网 RabbitMQ，接下里介绍 RocketMQ。

RocketMQ

根底概念

Tag

Tag（标签）能够看作子主题，它是音讯的第二级类型，用于为用户提供额定的灵活性。应用标签，同一业务模块不同目标的音讯就能够用雷同 Topic 而不同的 Tag 来标识。比方交易音讯又能够分为：交易创立音讯、交易实现音讯等，一条音讯能够没有 Tag。标签有助于放弃你的代码洁净和连贯，并且还能够为 RocketMQ 提供的查问零碎提供帮忙。

Group

RocketMQ 中，订阅者的概念是通过生产组（Consumer Group）来体现的。每个生产组都生产主题中一份残缺的音讯，不同生产组之间生产进度彼此不受影响，也就是说，一条音讯被 Consumer Group1 生产过，也会再给 Consumer Group2 生产。生产组中蕴含多个消费者，同一个组内的消费者是竞争生产的关系，每个消费者负责生产组内的一部分音讯。默认状况，如果一条音讯被消费者 Consumer1 生产了，那同组的其余消费者就不会再收到这条音讯。

Offset

在 Topic 的生产过程中，因为音讯须要被不同的组进行屡次生产，所以生产完的音讯并不会立刻被删除，这就须要 RocketMQ 为每个生产组在每个队列上保护一个生产地位（Consumer Offset），这个地位之前的音讯都被生产过，之后的音讯都没有被生产过，每胜利生产一条音讯，生产地位就加一。也能够这么说，Queue 是一个长度有限的数组，Offset 就是下标。

RocketMQ 架构

RabbitMQ 相似有生产阶段、存储阶段、生产阶段，相较 RabbitMQ 的架构，减少了 NameServer 集群，横向拓展能力较好。参考的 Kafka 做的设计，故也同样领有 NIO、PageCache、程序读写、零拷贝的技能，单机的吞吐量在十万级，横向拓展能力较强，官网申明集群下能承载万亿级吞吐。

存储阶段，能够通过配置可靠性优先的 Broker 参数来防止因为宕机丢音讯，简略说就是可靠性优先的场景都应该应用同步。

1、音讯只有长久化到 CommitLog（日志文件）中，即便 Broker 宕机，未生产的音讯也能从新复原再生产。

2、Broker 的刷盘机制：同步刷盘和异步刷盘，不论哪种刷盘都能够保障音讯肯定存储在 pagecache 中（内存中），然而同步刷盘更牢靠，它是 Producer 发送音讯后等数据长久化到磁盘之后再返回响应给 Producer。

Broker 通过主从模式来保障高可用，Broker 反对 Master 和 Slave 同步复制、Master 和 Slave 异步复制模式，生产者的音讯都是发送给 Master，然而生产既能够从 Master 生产，也能够从 Slave 生产。同步复制模式能够保障即便 Master 宕机，音讯必定在 Slave 中有备份，保障了音讯不会失落。

Consumer 的配置文件中，并不需要设置是从 Master 读还是从 Slave 读，当 Master 不可用或者忙碌的时候，Consumer 的读申请会被主动切换到从 Slave。有了主动切换 Consumer 这种机制，当一个 Master 角色的机器呈现故障后，Consumer 依然能够从 Slave 读取音讯，不影响 Consumer 读取音讯，这就实现了读的高可用。

如何达到发送端写的高可用性呢？在创立 Topic 的时候，把 Topic 的多个 Message Queue 创立在多个 Broker 组上（雷同 Broker 名称，不同 brokerId 机器组成 Broker 组），这样当 Broker 组的 Master 不可用后，其余组 Master 依然可用，Producer 依然能够发送音讯。

此架构下的 RocketMQ 不反对把 Slave 主动转成 Master，如果机器资源有余，须要把 Slave 转成 Master，则要手动进行 Slave 色的 Broker，更改配置文件，用新的配置文件启动 Broker。由此，在高可用场景下此问题变得辣手，故须要引入分布式算法的实现，谋求 CAP，但实际状况是不能共事满足 CA 的，在互联网场景下较多是在工夫 BASE 实践，优先满足 AP，尽可能去满足 C。RocketMQ 引入的是实现 Raft 算法的 Dledger，领有了选举能力，主从切换，架构拓扑图是这样的：

分布式算法中比拟经常听到的是 Paxos 算法，然而因为 Paxos 算法难于了解，且实现比拟艰难，所以不太受业界欢送。而后呈现新的分布式算法 Raft，其比 Paxos 更容易懂与实现，到现在在理论中使用的也曾经很成熟，不同的语言都有对其的实现。Dledger 就是其中一个 Java 语言的实现，其将算法方面的内容全副形象掉，这样开发人员只须要关系业务即可，大大降低应用难度。

事务音讯

1. 生产者将音讯发送至 Apache RocketMQ 服务端。

2.Apache RocketMQ 服务端将音讯长久化胜利之后，向生产者返回 Ack 确认音讯曾经发送胜利，此时音讯被标记为 ” 暂不能投递 ”，这种状态下的音讯即为半事务音讯。

3. 生产者开始执行本地事务逻辑。

4. 生产者依据本地事务执行后果向服务端提交二次确认后果（Commit 或是 Rollback），服务端收到确认后果后处理逻辑如下：

二次确认后果为 Commit：服务端将半事务音讯标记为可投递，并投递给消费者。二次确认后果为 Rollback：服务端将回滚事务，不会将半事务音讯投递给消费者。

5. 在断网或者是生产者利用重启的非凡状况下，若服务端未收到发送者提交的二次确认后果，或服务端收到的二次确认后果为 Unknown 未知状态，通过固定工夫后，服务端将对音讯生产者即生产者集群中任一生产者实例发动音讯回查。阐明 服务端回查的间隔时间和最大回查次数，请参见参数限度。

6. 生产者收到音讯回查后，须要查看对应音讯的本地事务执行的最终后果。

7. 生产者依据查看到的本地事务的最终状态再次提交二次确认，服务端仍依照步骤 4 对半事务音讯进行解决。

事务音讯生命周期

初始化：半事务音讯被生产者构建并实现初始化，待发送到服务端的状态。

事务待提交：半事务音讯被发送到服务端，和一般音讯不同，并不会间接被服务端长久化，而是会被独自存储到事务存储系统中，期待第二阶段本地事务返回执行后果后再提交。此时音讯对上游消费者不可见。

音讯回滚：第二阶段如果事务执行后果明确为回滚，服务端会将半事务音讯回滚，该事务音讯流程终止。

提交待生产：第二阶段如果事务执行后果明确为提交，服务端会将半事务音讯从新存储到一般存储系统中，此时音讯对上游消费者可见，期待被消费者获取并生产。

生产中：音讯被消费者获取，并依照消费者本地的业务逻辑进行解决的过程。此时服务端会期待消费者实现生产并提交生产后果，如果肯定工夫后没有收到消费者的响应，Apache RocketMQ 会对音讯进行重试解决。具体信息，请参见生产重试。

生产提交：消费者实现生产解决，并向服务端提交生产后果，服务端标记以后音讯曾经被解决（包含生产胜利和失败）。Apache RocketMQ 默认反对保留所有音讯，此时音讯数据并不会立刻被删除，只是逻辑标记已生产。音讯在保留工夫到期或存储空间有余被删除前，消费者依然能够回溯音讯从新生产。

音讯删除：Apache RocketMQ 依照音讯保留机制滚动清理最早的音讯数据，将音讯从物理文件中删除。更多信息，请参见音讯存储和清理机制。

RocketMQ 新倒退

在过来“分”往往是技术实现的斗争，而当初“合”才是用户的真正需要。RocketMQ 5.0 基于对立 Commitlog 扩大多元化索引，包含工夫索引、百万队列索引、事务索引、KV 索引、批量索引、逻辑队列等技术。在场景上同时撑持了 RabbitMQ、Kafka、MQTT、边缘轻量计算等产品能力，努力实现“音讯、事件、流”的扩大反对，云原生是支流。

更多信息可查看官网 Apache RocketMQ。

Kafka

Kafka 是一个分布式系统，由通过高性能 TCP 网络协议进行通信的服务器和客户端组成。它能够部署在本地和云环境中的裸机硬件、虚拟机和容器上。

服务器：Kafka 作为一个或多个服务器集群运行，能够逾越多个数据中心或云区域。其中一些服务器造成存储层，称为代理。其余服务器运行 Kafka Connect 以事件流的模式继续导入和导出数据，以将 Kafka 与您现有的零碎（例如关系数据库以及其余 Kafka 集群）集成。为了让您实现要害工作用例，Kafka 集群具备高度可扩展性和容错性：如果其中任何一台服务器产生故障，其余服务器将接管它们的工作以确保间断运行而不会失落任何数据。

客户端：它们容许您编写分布式应用程序和微服务，即便在呈现网络问题或机器故障的状况下，也能以容错的形式并行、大规模地读取、写入和处理事件流。Kafka 附带了一些这样的客户端，这些客户端由 Kafka 社区提供的 数十个客户端进行了裁减：客户端可用于 Java 和 Scala，包含更高级别的 Kafka Streams 库，用于 Go、Python、C/C++ 和许多其余编程语言以及 REST API。

架构

与后面两个 MQ 相似有生产阶段、存储阶段、生产阶段，相比 RocketMQ 这里的注册核心是用的 Zookeeper，Kafka 的诸多事件都依赖于 ZK，元数据管理、各个角色的注册、心跳、选举、状态保护，这里的角色包含 Boker、Topic、Partition、消费者组等。

所以这里也会带来 ZK watch 事件压力过大的问题，大量的 ZK 节点事件阻塞在队列中, 导致自旋锁, 导致 CPU 回升, 因为大量数量事件对象导致占用了大量的内存。

图中的 Controller 是 Kakfa 服务端 Broker 的概念，Broker 集群有多台，但只有一台 Broker 能够表演控制器的角色；某台 Broker 一旦成为 Controller，它用于以下势力：实现对集群成员治理、主题保护和分区的治理，如集群 broker 信息、Topic 保护、Partition 保护、分区选举 ISR、同步元信息给其余 Broker 等。

存储

topic 是逻辑上的概念，而 partition 是物理上的概念，即一个 topic 划分为多个 partition，每个 partition 对应一个 log 文件。

.log 文件：存储音讯数据的文件。
.index 文件：索引文件，记录一条音讯在 log 文件中的地位。
.snapshot 文件：记录着生产者最新的 offset。
.timeindex 工夫索引文件：
以后日志分段文件中建设索引的音讯的工夫戳，是在 0.10.0 版本后减少的，用于依据工夫戳疾速查找特定音讯的位移值，优化 Kafka 读取历史音讯迟缓的问题。为了保障工夫戳的枯燥递增，能够将 log.message.timestamp.type 设置成 logApendTime，而 CreateTime 不能保障是音讯写入工夫。

上图是三个 Broker、两个 topic、两个 partition 的 Broker 的存储状况，能够延长设想一下百万级 topic 的存储状况会很简单。

Rebalnce 问题

为了解决强依赖 Zookeeper 进行 Rebalance 带来的问题，Kafka 引入了 Coordinator 机制。
首先，触发 Rebalance（再平衡）操作的场景目前分为以下几种：消费者组内消费者数量发生变化，包含：

• 有新消费者退出
• 有消费者宕机下线，包含真正宕机，或者长时间 GC、网络提早导致消费者未在超时工夫外向 GroupCoordinator 发送心跳，也会被认为下线。
• 有消费者被动退出消费者组（发送 LeaveGroupRequest 申请）比方客户端调用了 unsubscrible() 办法勾销对某些主题的订阅
• 消费者组对应的 GroupCoordinator 节点产生了变动。
• 消费者组订阅的主题发生变化（增减）或者主题分区数量产生了变动。
• 节点扩容

更多信息可查看 Kafka 官网 Apache Kafka

Pulsar

在最高层，一个 Pulsar 实例由一个或多个 Pulsar 集群组成。一个实例中的集群能够在它们之间复制数据。

在 Pulsar 集群中：

一个或多个 broker 解决和负载平衡来自生产者的传入音讯，将音讯分派给消费者，与 Pulsar 配置存储通信以解决各种协调工作，将音讯存储在 BookKeeper 实例（又名 bookies）中，依赖于特定集群的 ZooKeeper 集群用于某些工作等等。
由一个或多个 bookie 组成的 BookKeeper 集群解决音讯的长久存储。
特定于该集群的 ZooKeeper 集群解决 Pulsar 集群之间的协调工作。
下图展现了一个 Pulsar 集群：

Pulsar 用 Apache BookKeeper 作为长久化存储，Broker 持有 BookKeeper client，把未确认的音讯发送到 BookKeeper 进行保留。
BookKeeper 是一个分布式的 WAL（Write Ahead Log）零碎，Pulsar 应用 BookKeeper 有上面几个便当：

• 能够为 topic 创立多个 ledgers：ledger 是一个只追加的数据结构，并且只有一个 writer，这个 writer 负责多个 BookKeeper 存储节点（就是 Bookies）的写入。Ledger 的条目会被复制到多个 bookies；
• Broker 能够创立、敞开和删除 Ledger，也能够追加内容到 Ledger；
• Ledger 被敞开后，只能以只读状态关上，除非要明确地写数据或者是因为 writer 挂掉导致的敞开；
• Ledger 只能有 writer 这一个过程写入，这样写入不会有抵触，所以写入效率很高。如果 writer 挂了，Ledger 会启动复原过程来确定 Ledger 最终状态和最初提交的日志，保障之后所有 Ledger 过程读取到雷同的内容；
• 除了保留音讯数据外，还会保留 cursors，也就是生产端订阅生产的地位。这样所有 cursors 生产完一个 Ledger 的音讯后这个 Ledger 就能够被删除，这样能够实现 ledgers 的定期翻滚从头写。

节点对等
从架构图能够看出，broker 节点不保留数据，所有 broker 节点都是对等的。如果一个 broker 宕机了，不会失落任何数据，只须要把它服务的 topic 迁徙到一个新的 broker 上就行。

broker 的 topic 领有多个逻辑分区，同时每个分区又有多个 segment。

writer 写数据时，首先会抉择 Bookies，比方图中的 segment1。抉择了 Bookie1、Bookie2、Bookie4，而后并发地写下去。这样这 3 个节点并没有主从关系，协调齐全依赖于 writer，因而它们也是对等的。

扩大和扩容
在遇到双十一等大流量的场景时，必须减少 consumer。
这时因为 broker 不存储任何数据，能够不便的减少 broker。broker 集群会有一个或多个 broker 做音讯负载平衡。当新的 broker 退出后，流量会主动从压力大的 broker 上迁徙过去。

对于 BookKeeper，如果对存储要求变高，比方之前存储 2 个正本当初须要存储 4 个正本，这时能够独自扩大 bookies 而不必思考 broker。因为节点对等，之前节点的 segment 又堆放参差，退出新节点并不必搬移数据。writer 会感知新的节点并优先选择应用。

容错机制
对于 broker，因为不保留任何数据，如果节点宕机了就相当于客户端断开，从新连贯其余的 broker 就能够了。
对于 BookKeeper，保留了多份正本并且这些正本都是对等的。因为没有主从关系，所以当一个节点宕机后，不必立刻复原。后盾有一个线程会查看宕机节点的数据备份进行复原。

在遇到双十一等大流量的场景时，必须减少 consumer。
这时因为 broker 不存储任何数据，能够不便的减少 broker。broker 集群会有一个或多个 broker 做音讯负载平衡。当新的 broker 退出后，流量会主动从压力大的 broker 上迁徙过去。

对于 BookKeeper，如果对存储要求变高，比方之前存储 2 个正本当初须要存储 4 个正本，这时能够独自扩大 bookies 而不必思考 broker。因为节点对等，之前节点的 segment 又堆放参差，退出新节点并不必搬移数据。writer 会感知新的节点并优先选择应用。

Pulsar 能够应用多租户来治理大集群。Pulsar 的租户能够跨集群散布，每个租户都能够有独自的认证和受权机制。租户也是存储配额、音讯 TTL 和隔离策略的治理单元。

在和其余组件或者生态对接方面，Pulsar 能够反对很多种音讯协定，对于存量零碎的 MQ 首次接入、切换 MQ 都很不便。

更多信息可查看 Pulsar 官网 Apache Pulsar

比照

此图摘抄自《面渣逆袭：RocketMQ 二十三问》
这个图没有 Pulsar 的信息，从网上看到的压测报告来看，Pulsar 吞吐量大略是 Kafka 的两倍左右，提早体现比 Kafka 低不少，Pulsar 的 I/O 隔离显著优于 Kafka。比拟详实的 Pulsar 和 Kafka 的比对能够查阅 StreamNative 的文章 Pulsar 和 Kafka 基准测试：Pulsar 性能精准解析（完整版），StreamNative 作为 Apache Pulsar 的商业化公司，数据和后果还是比拟牢靠的。

进阶

说实话介绍 MQ 的文章网上千千万，最好的学习路径还是官网文档，文中介绍的这几款 MQ 都在致力推广本人，所以文档在权威性、全面性、专业性、时效性都是无人能及其左右，当初的官网文档甚至本人做竞品比对，比方 RocketMQ 就本人放了比对表格在首页。所以要学好哪一款 MQ，就去看它的官网吧。

常言道，最好的学习办法是带着问题去寻找答案，在路上捡拾更多果实，减少经验值，疾速降级。很多人举荐费曼学习法，以教代学，按能够教他人的规范来学习，最终产出教学内容为目标来学习一个常识，能让本人高效学习。在我看来这很像绩效考核用的 OKR 工具，为我的项目设定要害成绩，实现胜利应该做什么？怎么做？而我写这篇文章是在实际费曼学习法。

所以，在这里我给出几个问题，读者能够依据本人的兴趣爱好带着问题去寻找答案吧。

如何保障音讯的可用性 / 可靠性 / 不失落呢？如何解决音讯反复的问题呢？程序音讯如何实现？怎么解决音讯积压？怎么实现分布式音讯事务的？半音讯？如何实现音讯过滤？

如果本人平时想到的问题太多，不晓得先看哪一个，那么本人想分明为什么要学这些知识点，哪个问题对于以后的本人收益最大。

参考资料

官网文档地址：
RabbitMQ 官网文档
Apache RocketMQ 官网文档
Apache Kafka 官网文档
Apache Pulsar 官网文档

互联网各文档（只列出了局部，若有疏漏，请指出）：
技术盘点：消息中间件的过来、当初和将来
Kafka 通信协定指南
新一代音讯队列 Pulsar
zkclient 大量节点事件导致 CPU 飙升
Part 3: The RabbitMQ Management Interface
kafka 学习十一 - 事务音讯
面渣逆袭：RocketMQ 二十三问
Pulsar 和 Kafka 基准测试：Pulsar 性能精准解析（完整版）