文章目录

  • Kafka
  • 1. Kafka如何保证不丢失消息?
  • 生产者数据的不丢失
  • 消费者数据的不丢失
  • Kafka集群中的broker的数据不丢失
  • 2. Kafka中的消息是否会丢失和重复消费?
  • 1. 消息发送
  • 2. 消息消费
  • 3. Kafka 的设计是什么样的呢?
  • 4. 数据传输的事务定义有哪三种
  • 5. Kafka 怎么判断一个节点存活
  • 6. 生产者是否直接将数据发送到 broker 的 leader (主节点)
  • 7. Kafka 消费者是否可以消费指定分区消息?
  • 8. Kafka 消息是采用 Pull 模式,还是 Push 模式?
  • 9. Kafka 存储在硬盘上的消息格式是什么? (存疑)
  • 10. 介绍一下kafka 的 ack 机制
  • 11. Kafka 的消费者如何消费数据


Kafka

1. Kafka如何保证不丢失消息?

生产者数据的不丢失

  • 如果是同步模式:

ack机制能够保证数据的不丢失,如果ack设置为0,风险很大,一般不建议设置为0。即使设置为1,也会随着leader宕机丢失数据。

producer.type=sync 
request.required.acks=1
  • 如果是异步模式:

也会考虑ack的状态,除此之外,异步模式下的有个buffer,通过buffer来进行控制数据的发送,有两个值来进行控制,时间阈值与消息的数量阈值,如果buffer满了数据还没有发送出去,有个选项是配置是否立即清空buffer。可以设置为-1,永久阻塞,也就数据不再生产。异步模式下,即使设置为-1。也可能因为程序员的不科学操作,操作数据丢失,比如kill -9,但这是特别的例外情况。

producer.type=async
request.required.acks=1
queue.buffering.max.ms=5000
queue.buffering.max.messages=10000 
queue.enqueue.timeout.ms = -1 
batch.num.messages=200

结论:producer有丢数据的可能,但是可以通过配置保证消息的不丢失。

消费者数据的不丢失

通过 offset commit 来保证数据的不丢失,Kafka自己记录了每次消费的offset数值,下次继续消费的时候,会接着上次的offset进行消费。

而offset的信息在Kafka0.8版本之前保存在Zookeeper中,在0.8版本之后保存到topic中,即使消费者在运行过程中挂掉了,再次启动的时候会找到offset的值,找到之前消费消息的位置,接着消费,由于 offset的信息写入的时候并不是每条消息消费完成后都写入的,所以这种情况有可能会造成重复消费,但是不会丢失消息。
唯一例外的情况是,我们在程序中给原本做不同功能的两个consumer组设置

Kafka SpoutConfig.bulider.setGroupid的时候设置成了一样的 groupid,这种情况会导致这两个组共享同一份数据,就会产生组A消费 partition1,partition2 中的消息,组B消费 partition3 的消息,这样每个组消费的消息都会丢失,都是不完整的。 为了保证每个组都独享一份消息数据,groupid一定不要重复才行。

Kafka集群中的broker的数据不丢失

每个broker中的partition我们一般都会设置有replication(副本)的个数,生产者写入的时候首先根据分发策略(有partition按partition,有key按key,都没有轮询)写入到leader中,follower(副本)再跟leader同步数据,这样有了备份,也可以保证消息数据的不丢失。

2. Kafka中的消息是否会丢失和重复消费?

要确定Kafka的消息是否丢失或重复,从两个方面分析入手:消息发送和消息消费。

1. 消息发送

Kafka消息发送有两种方式:同步(sync)和异步(async),默认是同步方式,可通过 producer.type属性进行配置。
Kafka通过配置 request.required.acks属性来确认消息的生产:

0---表示不进行消息接收是否成功的确认;
1---表示当Leader接收成功时确认;
-1---表示Leader和Follower都接收成功时确认;

综上所述,有6种消息生产的情况,下面分情况来分析消息丢失的场景:
(1) acks=0,不和 Kafka 集群进行消息接收确认,则当网络异常、缓冲区满了等情况时,消息可能丢失;
(2) acks=1、同步模式下,只有Leader确认接收成功后但挂掉了,副本没有同步,数据可能丢失;

2. 消息消费

Kafka 消息消费有两个 consumer 接口,Low-level API 和 High-level API:
Low-level API:消费者自己维护 offset 等值,可以实现对 Kafka 的完全控制;
High-level API:封装了对 parition 和 offset 的管理,使用简单;
如果使用高级接口High-level API,可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后,还没来得及消费就挂掉了,那么下次再消费时之前没消费成功的消息就“ 诡异”的消失了;
解决办法:
针对消息丢失:
同步模式下,确认机制设置为-1,即让消息写入Leader和Follower之后再确认消息发送成功;
异步模式下,为防止缓冲区满,可以在配置文件设置不限制阻塞超时时间,当缓冲区满时让生产者一直处于阻塞状态;
针对消息重复:将消息的唯一标识保存到外部介质中,每次消费时判断是否处理过即可。 消息重复消费及解决参考: 如何保证消息不被重复消费?(如何保证消息消费时的幂等性)

消息的重复消费问题,需要考虑幂等性,如果消费类型天生幂等,那么就没有必要去考虑重复消费的问题。
但是一般上 MQ 的任务都是一些比较耗时的任务,比如说调用第三方服务,此时可以采用第三方记录(redis),保存消息的唯一 id,定义消息的唯一id 以及时间戳的消费类型(待处理,过程中,失败/完成),如果是消费过程丢失,会导致消息长时间处于待处理的状态,我们可以另起一个定时任务,轮询一定时间间隔的任务,将它生产到兜底服务,由兜底服务去判断是否需要再次消费(比如说,一个 sms 服务,可以去查询当前消息 id 的短信是否已经成功发出,如果成功发出,则标记当前任务成功消费。)

3. Kafka 的设计是什么样的呢?

Kafka 将消息以主题为单位进行归纳。

  • 将向 Kafka 主题发布消息的程序称为生产者。
  • 将预订主题并消费消息的程序成为消费者。
  • Kafka 以集群的方式运行,可以由一个或多个服务组成,每个服务叫做一个 broker(中间人)。
  • 生产者通过网络将消息发送到 Kafka 集群,集群向消费者提供消息

4. 数据传输的事务定义有哪三种

  • 最多一次: 消息不会被重复发送,最多被传输一次,但也有可能一次不传输;
  • 最少一次: 消息不会被漏发送,最少被传输一次,但也有可能被重复传输;
  • 精确的一次(Exactly once): 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次,这是大家所期望的。

5. Kafka 怎么判断一个节点存活

主要有两个条件

  1. 必须可以维护和 ZooKeeper 的连接,ZooKeeper 通过心跳机制检查每个节点的连接;
  2. 如果节点是个 follower,他必须能及时的同步 leader 的写操作,延时不能太久。

6. 生产者是否直接将数据发送到 broker 的 leader (主节点)

生产者直接将数据发送到 broker 的 leader(主节点),不需要在多个节点进行分发,为了 帮助 producer 做到这点,所有的 Kafka 节点都可以及时的告知,哪些节点是活动的,目标 topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了。

7. Kafka 消费者是否可以消费指定分区消息?

Kafka 消费消息时,向 broker 发出 “fetch” 请求去消费特定分区的消息,同时,consumer 还指定消息在日志中的偏移量(offset),这样就可以消费从这个位置开始的消息。
消费者拥有 了 offset 的控制权,可以向后回滚去重新消费之前的消息,这是很有意义的。

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

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

9. Kafka 存储在硬盘上的消息格式是什么? (存疑)

消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32 校验码。

  • 版本号: 1 byte
  • CRC 校验码: 4 bytes
  • 具体的消息: n bytes

10. 介绍一下kafka 的 ack 机制

在Kafka发送数据的时候,每次发送消息都会有一个确认反馈机制,确保消息正常被收到。
可以通过设置request.required.acks 决定 ack 策略。

  • 0: 生产者不会等待 broker 的 ack,这个延迟最低但是存储的保证最弱。当 server 挂掉的时候就会丢数据;
  • 1:服务端会等待 ack 值。leader 副本确认接收到消息后发送 ack 。如果 leader 挂掉后,不确保是否复制完成,也就是说新 leader 可能会丢失数据;
  • -1:同样在 1 的基础上,服务端会等所有的 follower 的副本收到数据后, leader 才会发出 的 ack,这样数据就不会丢失。

11. Kafka 的消费者如何消费数据

消费者每次消费数据的时候,都会记录消费的物理偏移量(offset), 等到下次消费时,他会接着上次位置继续消费 。