1.请说明什么是传统的消息传递方法?

传统的消息传递方法包括两种:
排队:在队列中,一组用户可以从服务器中读取消息,每条消息都发送给其中一个人。
发布-订阅:在这个模型中,消息被广播给所有的用户。 

2. 请说明 Kafka 相对于传统的消息传递方法有什么优势? 

高性能:单一的 Kafka 代理可以处理成千上万的客户端,每秒处理数兆字节的读写操作,Kafka 性能远超过传统的 ActiveMQ、RabbitMQ 等,而且 Kafka 支持 Batch 操作;
可扩展:Kafka 集群可以透明的扩展,增加新的服务器进集群;
容错性:Kafka 每个Partition 数据会复制到几台服务器,当某个Broker 失效时,Zookeeper将通知生产者和消费者从而使用其他的 Broker; 

3. 在 Kafka 中 broker 的意义是什么?

在 Kafka 集群中,broker 指 Kafka 服务器。

Kafka面试题 

4. Kafka 中 的 ZooKeeper 是 什 么 ? Kafka 是 否 可 以 脱 离ZooKeeper 独立运行? 

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

不可以,不可能越过 Zookeeper 直接联系 Kafka broker,一旦 Zookeeper 停止工作,它就不能服务客户端请求。Zookeeper 主要用于在集群中不同节点之间进行通信,在 Kafka 中,它被用于提交偏移量,因此如果节点在任何情况下都失败了,它都可以从之前提交的偏移量中获取,除此之外,它还执行其他活动,如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。

5.解释一下,在数据制作过程中,你如何能从 Kafka 得到准确的信息? 

在数据中,为了精确地获得 Kafka 的消息,你必须遵循两件事: 在数据消耗期间避免重复,在数据生产过程中避免重复。
这里有两种方法,可以在数据生成时准确地获得一个语义:每个分区使用一个单独的写入器,每当你发现一个网络错误,检查该分区中的最后一条消息,以查看您的最后一次写入是否成功在消息中包含一个主键(UUID 或其他),并在用户中进行反复制

6.Kafka 为什么需要复制?

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

7. 如何保证 Kafka 的消息有序(☆☆☆☆☆)?

Kafka 对于消息的重复、丢失、错误以及顺序没有严格的要求。Kafka 只能保证一个partition 中的消息被某个consumer 消费时是顺序的,事实上,从Topic角度来说,当有多个 partition 时,消息仍然不是全局有序的。 

8.kafka 数据丢失问题,及如何保证?

kafka的ack机制:在kafka发送数据的时候,每次发送消息都会有一个确认反馈机制,确保消息正常的能够被收到。 

1)数据丢失:
acks=1 的时候(只保证写入 leader 成功),如果刚好 leader 挂了。数据会丢失。
acks=0 的时候,使用异步模式的时候,该模式下 kafka 无法保证消息,有可能会丢
2)brocker 如何保证不丢失:
acks=all : 所有副本都写入成功并确认。
retries = 一个合理值。
min.insync.replicas=2 消息至少要被写入到这么多副本才算成功。
unclean.leader.election.enable=false 关闭 unclean leader 选举,即不允许非 ISR 中的副本被
选举为 leader,以避免数据丢失。
3)Consumer 如何保证不丢失
如果在消息处理完成前就提交了 offset,那么就有可能造成数据的丢失。
enable.auto.commit=false 关闭自动提交 offset。处理完数据之后手动提交。 

9.kafka 的消费者方式?

consumer 采用 pull(拉)模式从 broker 中读取数据。
push(推)模式很难适应消费速率不同的消费者,因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息,但是这样很容易造成 consumer 来不及处理消息,典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。
对于 Kafka 而言,pull 模式更合适,它可简化 broker 的设计,consumer 可自主控制消费消息的速率,同时 consumer 可以自己控制消费方式——即可批量消费也可逐条消费,同时还能选择不同的提交方式从而实现不同的传输语义。
pull 模式不足之处是,如果 kafka 没有数据,消费者可能会陷入循环中,一直等待数据到达。为了避免这种情况,我们在我们的拉请求中有参数,允许消费者请求在等待数据到达的“长轮询”中进行阻塞。 

相关文章:

  • 2021-11-16
  • 2022-12-23
  • 2021-07-18
  • 2021-12-21
  • 2022-02-09
  • 2022-02-02
  • 2022-12-23
  • 2022-12-23
猜你喜欢
  • 2022-12-23
  • 2022-12-23
  • 2021-11-05
  • 2022-01-15
  • 2021-07-30
相关资源
相似解决方案