MQ:RabbitMQ与Kafka的一些问题总结

一:MQ

1.1 为什么使用MQ?MQ的优点

简要回答

异步处理 :相比于传统的串行、并行方式,提高了系统吞吐量

应用解耦 : 系统间通过消息通信,不用关心其他系统的处理。

流量削锋 : 可以通过消息队列长度控制请求量;可以缓解短时间内的高并发请求

日志处理 : 解决大量日志传输。

消息通讯 : 消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。

深入回答

主要是:解耦、异步、削峰

解耦

  1. A 系统发送数据到 BCD 三个系统,通过接口调用发送。
  2. 如果 E 系统也要 这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃…
  3. A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来
  4. 如果使用 MQ,A 系统产生一条数据, 发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可
  5. 这样下来,A 系统压根儿不需要去考虑要给谁发送数 据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。 就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 可以给它异步化解耦。

异步:避免同时写入需要等待前面的内容消费完了再开始消费后面的数据

  1. A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、 200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户 感觉搞个什么东西,慢死了慢死了。
  2. 用户通过浏览器发起请求。如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从 接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms。

削峰:减少高峰时期对服务器压力。

1.2 消息队列有什么优缺点

好处便是:解耦、异步、削峰

缺点:

  1. 系统可用性降低

    现在系统加入了一个消息队列进去,那消息队列挂了,系统便不可用。因此,系统可用性会降低;

  2. 系统复杂度提高

    加入了消息队列,便要考虑很多方面的问题,比如:一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此,需要考虑的东西更多,复杂 性增大。

1.3 MQ的选择

一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用 的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,不推荐用这个了;

后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师 去深入研究和掌控它,对公司而言,几乎处于不可控的状态

中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是 不错的选择;

大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选 择。

如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高。

1.4 MQ 常见问题及解决方法?

常见问题1:消息的顺序问题

消息有序指的是可以按照消息的发送顺序来消费

解决方案: (1)保证生产者 - MQServer - 消费者是一对一对一的关系

常见问题2:消息的重复问题

造成消息重复的根本原因是:网络不可达

所以解决这个问题的办法就是绕过这个问题。那么问题就变成了:如果消费端收到两条一样的消息,应该怎样处理
消费端处理消息的业务逻辑保持幂等性
只要保持幂等性,不管来多少条重复消息,最后处理的结果都一样。
保证每条消息都有唯一编号

保证消息处理成功和去重表的日志同时出现。

利用一张日志表记录已经处理成功的消息的 ID如果新到的消息ID 已经在日志表中,那么就不再处理这条消息。

二:RabbitMQ

2.1 什么是RabbitMQ

RabbitMQ是一款开源的,Erlang编写的,基于AMQP协议的消息中间件

2.2 Rabbitmq 的使用场景

(1)服务间异步通信
(2)顺序消费
(3)定时任务
(4)请求削峰

2.3 RabbitMQ的工作模式

2.3.1 WorkQueue工作队列模式

MQ:RabbitMQ与Kafka的一些问题总结_第1张图片
1.生产者产生消息,将消息放入队列

2.消息的消费者(consumer) 监听消息队列,如果队列中有消息,就消费掉;消息被拿走后,自动从队列中删除

隐患消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失

这里可以设置成手动的ack,但如果设置成手动ack,处理完后要及时发送ack消息给队列,否则会造成内存溢出

2.3.2 Pub/Sub订阅模式

MQ:RabbitMQ与Kafka的一些问题总结_第2张图片
1、每个消费者监听自己的队列
2、生产者将消息发给broker,由交换机将消息转发到绑定此交换机的每个队列,每个绑定交换机的队列都将接收到消息

Exchange (交换机)只负责转发消息,不具备存储消息的能力,因此如果没有任何队列与Exchange绑定,或者没有符合路由规则的队列,那么消息会丢失!

2.3.3 Route路由模式

MQ:RabbitMQ与Kafka的一些问题总结_第3张图片
1.队列与交换机的绑定,不能是任意绑定了,而是要指定一个RoutingKey (路由key)

2.消息的发送方在向Exchange发送消息时,也必须指定消息的RoutingKey

3.Exchange不再把消息交给每一个绑定的队列, 而是根据消息的Routing Key进行判断只有队列的Routingkey与消息的Routing key完全一致, 才会接收到消息

图例说明:

P:生产者,向Exchange发送消息,发送消息时,会指定-个routing key
X: Exchange (交换机),接收生产者的消息,然后把消息递交给与routing key完全匹配的队列
C1: 消费者,其所在队列指定了需要routing key为error的消息
C2:消费者,其所在队列指定了需要routing key为info、 error. warning的消

Routing模式要求队列在绑定交换机时要指定routing key,消息会转发到符命routing key的队列。

2.3.4 Topic通配符模式

MQ:RabbitMQ与Kafka的一些问题总结_第4张图片
Topic类型与Direct相比,都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符!

Routingkey 一般都是有一个或多个单词组成,多个单词之间以”.”分割,例如: item.insert

通配符规则:

#:匹配一个或多个词
*:匹配不多不少恰好1个词

举例:

item.#:能够匹配item.insert.abc 或者 item.insert
item.*:只能匹配item.insert

MQ:RabbitMQ与Kafka的一些问题总结_第5张图片
图解:

  • 红色Queue:绑定的是usa.# ,因此凡是以 usa.开头的routing key 都会被匹配到
  • 黄色Queue:绑定的是#.news ,因此凡是以 .news结尾的 routing key 都会被匹配

2.4 如何保证RabbitMQ消息的顺序性

拆分多个 queue,每个 queue 一个 consumer,就是多一些 queue 而已;

或者就一个 queue 但是对应一个 consumer,然后这个 consumer 内部用内存队列做排队,然后分发给底层不同的 worker 来处理

2.5 消息如何分发

若该队列至少有一个消费者订阅,消息将以循环(round-robin)的方式发送给消费者。每条消息只会分发给一个订阅的消费者(前提是消费者能够正常处理消息并进行确认)。

通过路由可实现多消费的功能

2.6 消息怎么路由

消息提供方->路由->一至多个队列消息发布到交换器时,消息将拥有一个路由键(routing key),在消息创建时设定。

通过队列路由键,可以把队列绑定到交换器上。

消息到达交换器后,RabbitMQ 会将消息的路由键与队列的路由键进行匹配(针对不同的交换器有不同的路由规则);常用的交换器主要分为一下三种:

  1. fanout:如果交换器收到消息,将会广播到所有绑定的队列上
  2. direct:如果路由键完全匹配,消息就被投递到相应的队列
  3. topic:可以使来自不同源头的消息能够到达同一个队列。 使用 topic 交换器时,可以使用通配符

2.7 消息基于什么传输

由于 TCP 连接的创建和销毁开销较大,且并发数受系统资源限制,会造成性能瓶颈。

RabbitMQ 使用信道的方式来传输数据

信道建立在真实的 TCP 连接内的虚拟连接,且每条 TCP 连接上的信道数量没有限制

2.8 如何保证消息不被重复消费?或者说,如何保证消息消费时的幂等性?

出现重复消费:

正常情况下,消费者在消费消息的时候,消费完毕后,会发送一个确认消息给消息队列,消息队列就知道该消息被消费了,就会将该消息从消息队列中删除;
但是因为网络传输等等故障,确认信息没有传送到消息队列,导致消息队列不知道自己已经消费过该消息了,再次将消息分发给其他的消费者

一个解决思路是:保证消息的唯一性,就算是多次传输,不要让消息的多次消费带来影响;保证消息等幂性;

比如:在写入消息队列的数据做唯一标示,消费消息时,根据唯一标识判断是否消费过;

  1. 假设你有个系统,消费一条消息就往数据库里插入一条数据,要是你一个消息重复两次,你不就插入了两条,这数据不就错了?
  2. 但是你要是消费到第二次的时候,自己判断一下是否已经消费过了,若是就直接扔了,这样不就保留了一条数据,从而保证了数据的正确性。

2.9 如何确保消息正确地发送至RabbitMQ? 如何确保消息接收方消费了消息?

发送方确认模式将信道设置成 confirm 模式(发送方确认模式),则所有在信道上发布的消息都会被指派一个唯一的 ID。

  1. 一旦消息被投递到目的队列后,或者消息被写入磁盘后(可持久化的消息),信道会发送一个确认给生产者(包含消息唯一 ID)
  2. 如果 RabbitMQ 发生内部错误从而导致消息丢失,会发送一条nack(notacknowledged,未确认)消息。

发送方确认模式是异步的,生产者应用程序在等待确认的同时,可以继续发送消息。

  1. 当确认消息到达生产者应用程序,生产者应用程序的回调方法就会被触发来处理确认消息
  2. 接收方确认机制消费者接收每一条消息后都必须进行确认(消息接收和消息确认是两个不同操作)。
  3. 只有消费者确认了消息,RabbitMQ 才能安全地把消息从队列中删除

这里并没有用到超时机制,RabbitMQ 仅通过 Consumer 的连接中断来确认是否需要重新发送消息

也就是说,只要连接不中断,RabbitMQ 给了Consumer 足够长的时间来处理消息。

2.10 如何保证RabbitMQ消息的可靠传输

消息不可靠的情况可能是消息丢失,劫持等原因;丢失又分为:

  1. 生产者丢失消息、
  2. 消息列表丢失消息、
  3. 消费者丢失消息;
  4. 生产者丢失消息:

从生产者弄丢数据这个角度来看,RabbitMQ提供 transaction和confirm模式来确保生产者不丢消息;

2.10.1 transaction机制

transaction机制就是说:发送消息前,开启事务(channel.txSelect()),然后发送消息,如果发送过程中出现什么异常,事务就会回滚

(channel.txRollback()),如果发送成功则提交事务

(channel.txCommit())。然而,这种方式有个缺点:吞吐量下降;

2.10.2 confirm模式

confirm模式用的居多:一旦channel进入confirm模式,所有在该信道上发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后;

rabbitMQ就会发送一个ACK给生产者(包含消息的唯一ID),这就使得生产者知道消息已经正确到达目的队列了;

如果rabbitMQ没能处理该消息,则会发送一个Nack消息给你,你可以进行重试操作

2.10.3 消息队列丢数据

息队列丢数据:需要开启消息持久化
处理消息队列丢数据的情况,一般是开启持久化磁盘的配置

这个持久化配置可以和confirm机制配合使用,你可以在消息持久化磁盘后,再给生产者发送一个Ack信号。这样,如果消息持久化磁盘之前,rabbitMQ阵亡了,那么生产者收不到Ack信号,生产者会自动重发

2.10.4 如何持久化

  1. 将queue的持久化标识durable设置为true,则代表是一个持久的队列
  2. 发送消息的时候将deliveryMode=2

这样设置以后,即使rabbitMQ挂了,重启后也能恢复数据

2.10.5 消费者丢失消息:

消费者丢数据一般是因为采用了自动确认消息模式,改为手动确认消息即可

消费者在收到消息之后,处理消息之前,会自动回复RabbitMQ已收到消息;如果这时处理消息失败,就会丢失该消息;

解决方案:处理消息成功后,手动回复确认消息。

2.11 为什么不应该对所有的 message 都使用持久化机制

首先:必然导致性能的下降

因为写磁盘比写 RAM 慢的多,message 的吞吐量可能有 10 倍的差距。

其次:message 的持久化机制用在 RabbitMQ 的内置 cluster 方案时会出现“坑爹”问题

若 message 设置了 persistent 属性,但 queue 未设置 durable 属性,那么当该 queue 的 owner node 出现异常后在未重建该 queue 前发往该 queue 的 message 将被 blackholed
若 message 设置了 persistent 属性,同时 queue 也设置了durable 属性,那么当 queue 的 owner node 异常且无法重启的情况下,则该 queue 无法在其他 node 上重建,只能等待其 owner node 重启后,才能恢复该 queue 的使用,而在这段时间内发送给该 queue 的 message 将被 blackholed

是否要对 message 进行持久化,需要综合考虑性能需要,以及可能遇到的问题。

若想达到 100,000 条/秒以上的消息吞吐量(单 RabbitMQ 服务器),

  1. 使用其他的方式来确保 message 的可靠 delivery
  2. 使用非常快速的存储系统以支持全持久化(例如使用 SSD)。
  3. 另外一种处理原则是:仅对关键消息作持久化处理(根据业务重要程度),且应该保证关键消息的量不会导致性能瓶颈。

三:Kafka

3.1 什么是Apache Kafka

Apache Kafka是由Apache开发的一种发布订阅消息系统,它是一个分布式的、分区的和重复的日志服务

是一个分布式、分区的、多副本的、多订阅者基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志、访问日志,消息服务等等

3.2 什么是传统的消息传递方法

传统的消息传递方法包括两种

  1. 排队:在队列中,一组用户可以从服务器中读取消息,每条消息都发送给其中一个人
  2. 发布-订阅:在这个模型中,消息被广播给所有的用户

3.3 Kafka相对传统技术有什么优势

快速:单一的Kafka代理可以处理成千上万的客户端,每秒处理数兆字节的读写操作。

可伸缩:在一组机器上对数据进行分区和简化,以支持更大的数据

持久:消息是持久性的,并在集群中进行复制,以防止数据丢失

设计:它提供了容错保证和持久性

3.4 broker的意义是什么

Kafka集群中包含的一个或多个服务器,服务器节点称为Broke

3.5 Kafka服务器能接收到的最大信息是多少

Kafka服务器可以接收到的消息的最大大小是一百万字节

3.6 Kafka的Zookeeper是什什么?可以在没有Zookeeper的情况下使用Kafka吗?

Zookeeper是一个开放源码的、高性能的协调服务,它用于Kafka的分布式应用

不可以在没有Zookeeper的情况下使用Kafka

Zookeeper主要用于在集群中不同节点之间进行通信

  1. 在Kafka中,它被用于提交偏移量,因此如果节点在任何情况下都失败了,它都可以从之前提交的偏移量中获取
  2. 除此之外,它还执行其他活动,如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。

3.7 Kafka的用户如何消费信息

在Kafka中传递消息是通过使用sendfile API完成的。

它支持将字节从套接口转移到磁盘,通过内核空间保存副本,并在内核用户之间调用内核。

3.8 如何提高远程用户的吞吐量

如果用户位于与broker不同的数据中心,则可能需要调优套接口缓冲区大小,以对长网络延迟进行摊销。

3.9 在数据制作过程中,如何能从Kafka得到准确的信息

在数据中,为了精确地获得Kafka的消息,你必须遵循两件事: 在数据消耗期间避免重复在数据生产过程中避免重复

有两种方法,可以在数据生成时准确地获得一个语义

  1. 每个分区使用一个单独的写入器,每当你发现一个网络错误,检查该分区中的最后一条消息,以查看您的最后一次写入是否成功
  2. 在消息中包含一个主键(UUID或其他),并在用户中进行反复制

3.10broker什么时候离开ISR

如果一个副本从leader中脱离出来,将会
从ISR中删除

3.11 Kafka为什么需要复制

确保了任何已发布的消息不会丢失,并且可以在机器错误、程序错误或更常见些的软件升级中使用。

3.12 如果副本在ISR中停留了很长时间表明什么?

如果一个副本在ISR中保留了很长一段时间,那么它就表明,跟踪器无法像在leader收集数据那样快速地获取数据

3.14 如果首选的副本不在ISR中会发生什么?

如果首选的副本不在ISR中,控制器将无法将leadership转移到首选的副本

3.15 有可能在生产后发生消息偏移吗

大多数队列系统中作为生产者的类无法做到这一点,它的作用是触发并忘记消息。broker将完成剩下的工作,比如使用id进行适当的元数据处理、偏移量等。

作为消息的用户,你可以从Kafka broker中获得补偿。如果你注视SimpleConsumer类,你会注意到它会获取包括偏移量作为列表的MultiFetchResponse对象。

此外,当对Kafka消息进行迭代时,你会拥有包括偏移量和消息发送的MessageAndOffset对象。

3.16 Kafka部分名词解释

MQ:RabbitMQ与Kafka的一些问题总结_第6张图片

Broker:消息中间件处理结点,一个Kafka节点就是一个broker,多个broker可以组成一个Kafka集群

Topic一类消息,例如page view日志、click日志等都可以以topic的形式存在,Kafka集群能够同时负责多个topic的分发

Partitiontopic物理上的分组,一个topic可以分为多个partition,每个partition是一个有序的队列

Segmentpartition物理上由多个segment组成

offset每个partition都由一系列有序的、不可变的消息组成,这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息

3.17 分析过程

MQ:RabbitMQ与Kafka的一些问题总结_第7张图片

分析过程分为以下4个步骤

  1. topic中partition存储分布
  2. partition中文件存储方式
  3. partition中segment文件存储结构
  4. 在partition中如何通过offset查找messag

3.17.1 topic中partition存储分布

在Kafka文件存储中,同一个topic下有多个不同partition,每个partition为一个目录

partiton命名规则为topic名称+有序序号第一个partiton序号从0开始,序号最大值为partitions数量减1。

实验环境中Kafka集群只有一个broker,xxx/message-folder为数据文件存储根目录,

在Kafka broker中server.properties文件配置(参数log.dirs=xxx/message-folder),

例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4
存储路径和目录规则为:xxx/message-folder

	|--report_push-0
    |--report_push-1
    |--report_push-2
    |--report_push-3
    |--launch_info-0
    |--launch_info-1
    |--launch_info-2
    |--launch_info-3

3.17.2 partition中文件存储方式

partition中文件存储方式

  1. 每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等,这种特性方便old segment file快速被删除。
  2. 每个partiton只需要支持顺序读写就行了,segment文件生命周期由服务端配置参数决定

这样做的好处就是能快速删除无用文件,有效提高磁盘利用率

3.17.3 partiton中segment文件存储结构

Kafka文件系统partition存储方式
深入分析partion中segment file组成和物理结构

  1. segment file组成:由2大部分组成,分别为index filedata file,此2个文件一一对应,成对出现,后缀".index"和“.log”分别表示为segment索引文件、数据文件
  2. segment文件命名规则:partition全局的第一个segment从0开始,后续每个segment文件名为上一个segment文件最后一条消息的offset值。数值最大为64位long大小,19位数字字符长度,没有数字用0填充。

3.17.4 在partition中如何通过offset查找message

例如读取offset=368776的message,需要通过下面2个步骤查找。

  1. 第一步查找segment file
    其中00000000000000000000.index表示最开始的文件,起始偏移量(offset)为0.第二个文件00000000000000368769.index的消息量起始偏移量为368770= 368769 + 1.
    同样,第三个文件00000000000000737337.index的起始偏移量为737338=737337 + 1,其他后续文件依次类推,以起始偏移量命名并排序这些文件,只要根据offset 二分查找文件列表,就可以快速定位到具体文件。
    当offset=368776时定位到00000000000000368769.index|log
  2. 第二步通过segment file查找message
    通过第一步定位到segment file,当offset=368776时,依次定位到 00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址,然后再通过 00000000000000368769.log顺序查找直到offset=368776为止

3.18 Kafka高效文件存储设计特点

Kafka把topic中一个parition大文件分成多个小文件段,通过多个小文件段,就容易定期清除或删除已经消费完文件,减少磁盘占用

通过索引信息可以快速定位message和确定response的最大大小

通过index元数据全部映射到memory,可以避免segment file的IO磁盘操作

通过索引文件稀疏存储,可以大幅降低index文件元数据占用空间大小

3.19 topic的分区partition分段segment以及索引

Kafka中的Message是以topic为基本单位组织的,不同的topic之间是相互独立的。

每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定
的),每个partition存储一部分Message
MQ:RabbitMQ与Kafka的一些问题总结_第8张图片

3.19.1 Partition的数据文件

Partition中的每条Message由offset来表示它在这个partition中的偏移量

offset不是该Message在partition数据文件中的实际存储位置,而是逻辑上一个值,它唯一确定了partition中的一条Message

可以认为offset是partition中Message的id,partition中的每条Message包含了以下三个属性:

  1. offset
    offset为long型
  2. MessageSize
    MessageSize为int32,表示data有多大
  3. data
    data为message的具体内容

Partition的数据文件则包含了若干条上述格式的Message,按offset由小到大排列在一起。它的实现类为FileMessageSet

3.20 Kafka是如何解决查找效率的的问题

有两种方法:1) 分段 2) 索引。

3.20.1 数据文件的分段

比如有100条Message,它们的offset是从0到99

  1. 假设将数据文件分成5段,第一段为0-19,第二段为20-39,以此类推,每段放在一个单独的数据文件里面,数据文件以该段中最小的offset命名。
  2. 这样在查找指定offset的Message的时候,用二分查找就可以定位到该Message在哪个段中

3.20.2 为数据文件建索引

数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了,为进一步提高查找的效率Kafka为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为.index

索引文件中包含若干个索引条目,每个条目表示数据文件中一条Message的索引。索引包含两个部分(均为4个字节的数字),分别为相对offset和position

  1. 相对offset:因为数据文件分段以后,每个数据文件的起始offset不为0,相对offset表示这条Message相对于其所属数据文件中最小的offset的大小

    举例,分段后的一个数据文件的offset是从20开始,那么offset为25的Message在index文件中的相对offset就是25-20 = 5。
    存储相对offset可以减小索引文件占用的空间。

  2. position,表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。

3.21 Kafka 新建的分区会在哪个目录下创建

在启动 Kafka 集群之前,我们需要配置好 log.dirs 参数其值是 Kafka 数据的存放目录

这个参数可以配置多个目录,目录之间使用逗号分隔,通常这些目录是分布在不同的磁盘上用于提高读写性能

3.22 Kafka 与传统消息系统之间有三个关键区别

(1).Kafka 持久化日志,这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统:它以集群的方式运行,可以灵活伸缩,在内部通过复制数据提升容错能力和高可用性
(3).Kafka 支持实时的流式处理

3.23 Kafka 消息是采用 Pull 模式,还是 Push 模式?

Kafka 遵循了一种大部分消息系统共同的传统的设计:producer 将消息推送到 broker,consumer 从 broker 拉取消息

Kafka 选取了传统的 pull 模式

Pull 模式的另外一个好处consumer 可以自主决定是否批量的从 broker 拉取数据

Pull 有个缺点是,如果 broker 没有可供消费的消息,将导致consumer 不断在循环中轮询,直到新消息到 达

你可能感兴趣的:(#,Interview,kafka,rabbitmq,分布式)