18道kafka高频面试题哪些你还不会?(含答案和思维导图)

  • 时间:
  • 浏览:1
  • 来源:幸运飞艇APP下载_幸运飞艇APP官方

生产者在主题上发布消息:

bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topicHello-Kafka

注意这里的 IP 是 server.properties 中的 listeners 的配置。接下来每个新行随后 输入三根新消息。

消费者接受消息:

bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topicHello-Kafka --from-beginning

這個 那些的问题图片比较系统,回答出 kafka 的系统特点,leader 和 follower 的关系,消息读写的顺序即可。

关于Kafka的知识总结了个思维导图

出现“活锁”的情况表,是它持续的发送心跳,随后 没人 处里。为了预防消费者在這個 情况表下无缘无故持有分区,亲戚亲戚人们人们人们使用 max.poll.interval.ms 活跃检测机制。 在此基础上,不可能 你调用的 poll 的频率大于最大间隔,则客户端将主动地背叛组,以便這個 消费者接管该分区。 指在這個 情况表时,我能 看多 offset 提交失败(调用commitSync()引发的 CommitFailedException)。这是有两种安全机制,保障只有活动成员要能提交 offset。随后要留在组中,你前要持续调用 poll。

消费者提供另一个配置设置来控制 poll 循环:

max.poll.interval.ms:增大 poll 的间隔,还都后能 为消费者提供更多的时间去处里返回的消息(调用 poll(long)返回的消息,通常返回的消息不会 一批)。缺点是此值越大不可能 延迟组重新平衡。

max.poll.records:此设置限制每次调用 poll 返回的消息数,原本还都后能 更容易的预测每次 poll 间隔要处里的最大值。通过调整此值,还都后能 减少 poll 间隔,减少重新平衡分组的

对于消息处里时间不可预测地的情况表,那些选项是不足的。 处里這個 情况表的推荐最好的法律辦法 是将消息处里移到原本线程中,让消费者继续调用 poll。 随后 前要注意确保已提交的 offset 不超过实际位置。另外,你前要禁用自动提交,并只有在线程完成处里后才为记录手动提交偏移量(取决于你)。 前要注意,你前要 pause 暂停分区,不要 从 poll 接收到新消息,让线程处里完随后 返回的消息(不可能 你的处都后能 力比拉取回息的慢,那创建新线程将意味你机器内存溢出)。

人太好还是得结合业务来思考,我这里给哪几个思路:

比如你拿个数据要写库,你先根据主键查一下,不可能 这数据不会 了,你就别插入了,update 一下好吧。

比如你是写 Redis,那没那些的问题图片了,反正每次不会 set,碳酸岩幂等性。

比如你不会 上面另一个场景,那做的稍微简化這個 ,你前要让生产者发送每条数据的随后 ,上面加另一个全局唯一的 id,类式订单 id 类式的东西,我能 这里消费到了随后 ,先根据這個 id 去比如 Redis 里查一下,随后 消费过吗?不可能 没人 消费过,你就处里,随后 這個 id 写 Redis。不可能 消费过了,那你就别处里了,保证别重复处里相同的消息即可。

比如基于数据库的唯一键来保证重复数据不要 重复插入多条。不可能 有唯一键约束了,重复数据插入只会报错,不要 意味数据库中出现脏数据。欢迎亲戚亲戚人们人们人们关注我的公种浩【线程员追风】,2019年多家公司java面试题收集了30多道30多页pdf文档,文章不会 在上面更新,收集的资料也会插进上面。

(1)解耦:

允许你独立的扩展或修改两边的处里过程,随后 我确保它们遵守同样的接口约束。

(2)冗余:

消息队列把数据进行持久化直到它们不可能 被完整版处里,通过這個 最好的法律辦法 规避了数据丢失风险。這個 消息队列所采用的”插入-获取-删除”范式中,在把另一个消息从队列中删除随后 ,前要你的处里系统明确的指出该消息不可能 被处里完毕,从而确保你的数据被安全的保存直到你使用完毕。

(3)扩展性:

不可能 消息队列解耦了你的处里过程,随后增大消息入队和处里的频率是很容易的,随后 我另外增加处里过程即可。

(4)灵活性 & 峰值处都后能 力:

在访问量剧增的情况表下,应用仍然前要继续发挥作用,随后 原本的突发流量从不常见。不可能 为以能处里类式峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列要能使关键组件顶住突发的访问压力,而不要 不可能 突发的超负荷的请求而完整版崩溃。

(5)可恢复性:

系统的一次要组件失效时,不要 影响到整个系统。消息队列降低了线程间的耦合度,随后即使另一个处里消息的线程挂掉,加入队列中的消息仍然还都后能 在系统恢复后被处里。

(6)顺序保证:

在大多使用场景下,数据处里的顺序都很重要。大次要消息队列原本随后 排序的,之还都后能 保证数据会按照特定的顺序来处里。(Kafka 保证另一个 Partition 内的消息的有序性)

(7)缓冲:

促使控制和优化数据流经过系统的速度,处里生产消息和消费消息的处里速度不一致的情况表。

(8)异步通信:

随后随后 ,用户要我随后 前要立即处里消息。消息队列提供了异步处里机制,允许用户把另一个消息插进队列,但从不立即处里它。想向队列中插进哪几个消息就放哪几个,随后 在前要的随后 再去处里它们。

Kafka 分布式的单位是 partition,同另一个 partition 用另一个 write ahead log 组织,随后还都后能 保证 FIFO 的顺序。不同 partition 之间只有保证顺序。随后 绝大多数用户都还都后能 通过 message key 来定义,不可能 同另一个 key 的 message 还都后能 保证只发送到同另一个 partition。

Kafka 中发送 1 条消息的随后 ,还都后能 指定(topic, partition, key) 3 个参数。partiton 和 key 是可选的。不可能 你指定了 partition,那随后 所有消息发往同 另一个 partition,随后 有序的。随后 在消费端,Kafka 保证,1 个 partition 只有被1 个 consumer 消费。不可能 你指定 key( 比如 order id),具有同 1 个 key 的所有消息,会发往同 1 个 partition。

kafka 使用 seek(TopicPartition, long)指定新的消费位置。用于查找服务器保留的最早和最新的 offset 的特殊的最好的法律辦法 也可用(seekToBeginning(Collection) 和seekToEnd(Collection))

Kafka 最初考虑的那些的问题图片是,customer 应该从 brokes 拉取回息还是 brokers 将消息推送到 consumer,也随后 pull 还 push。在这方面,Kafka 遵循了有两种大次要消息系统同去的传统的设计:producer 将消息推送到 broker,consumer 从broker 拉取回息。

這個 消息系统比如 Scribe 和 Apache Flume 采用了 push 模式,将消息推送到下游的 consumer。原本做有好处不会 坏处:由 broker 决定消息推送的速度,对于不同消费速度的 consumer 就不太好处里了。消息系统都致力于让 consumer 以最大的速度最快速的消费消息,但不幸的是,push 模式下,当 broker 推送的速度远大于 consumer 消费的速度时,consumer 恐怕就要崩溃了。最终 Kafka 还是选着了传统的 pull 模式。

Pull 模式的另外另一个好处是 consumer 还都后能 自主决定与否批量的从 broker 拉取数据 。Push 模式前要在我不知道下游 consumer 消费能力和消费策略的情况表下决定是立即推送每条消息还是缓存随后 批量推送。不可能 为了处里 consumer 崩溃而采用较低的推送速度,将不可能 意味一次只推送较少的消息而造成浪费。Pull 模式下,consumer 就还都后能 根据买车人的消费能力去决定那些策略。

Pull 有个缺点是,不可能 broker 没人 可供消费的消息,将意味 consumer 不断在循环中轮询,直到新消息到 t 达。为了处里这点,Kafka 有个参数还都后能 让 consumer阻塞知道新消息到达(当然也还都后能 阻塞知道消息的数量达到某个特定的量原本就还都后能 批量发送)。

(1).Kafka 持久化日志,那些日志还都后能 被重复读取和无限期保留

(2).Kafka 是另一个分布式系统:它以集群的最好的法律辦法 运行,还都后能 灵活伸缩,在组织组织结构通过克隆技术数据提升容错能力和高可用性

(3).Kafka 支持实时的流式处里

(1)节点前要还都后能 维护和 ZooKeeper 的连接,Zookeeper 通过心跳机制检查每个节点的连接

(2)不可能 节点是个 follower,他前要能及时的同步 leader 的写操作,延时只有不要

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

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

在 Kafka 中,它被用于提交偏移量,随后 不可能 节点在任何情况表下都失败了,它都还都后能 从随后 提交的偏移量中获取除此之外,它还执行這個 活动,如: leader 检测、分布式同步、配置管理、识别新节点多会儿背叛或连接、集群、节点实时情况表等等。

request.required.acks 有另一个值 0 1 -1(all)

0:生产者不要 等待 broker 的 ack,這個 延迟最低随后 存储的保证最弱当 server 挂掉的随后 就会丢数据。

1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 随后 不可能 leader挂掉后他不确保与否克隆技术完成新 leader 也会意味数据丢失。

-1(all):服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack,原本数据不要 丢失

1、怎么获取 topic 主题的列表

2、生产者和消费者的命令行是那些?

3、consumer 是推还是拉?

4、讲讲 kafka 维护消费情况表跟踪的最好的法律辦法

5、讲一下主从同步

6、为那些前要消息系统,mysql 只有满足需求吗?

7、Zookeeper 对于 Kafka 的作用是那些?

8、数据传输的事务定义有哪有两种?

9、Kafka 判断另一个节点与否还活着有那另一个条件?

10、Kafka 与传统 MQ 消息系统之间有另一个关键区别

11、讲一讲 kafka 的 ack 的有两种机制

13、消费者故障,出现活锁那些的问题图片怎么处里?

14、怎么控制消费的位置

15、kafka 分布式(不会 单机)的情况表下,怎么保证消息的顺序消费?

16、kafka 的高可用机制是那些?

17、kafka 怎么减少数据丢失

18、kafka 怎么不消费重复数据?比如扣款,亲戚亲戚人们人们人们只有重复的扣。

大次要消息系统在 broker 端的维护消息被消费的记录:另一个消息被收集到consumer 后 broker 就马上进行标记不可能 等待 customer 的通知后进行标记。原本也还都后能 在消息在消费后立马就删除以减少空间占用。

随后 原本会不要 有那些那些的问题图片呢?不可能 三根消息发送出去随后 就立即被标记为消费过的,旦 consumer 处里消息时失败了(比如线程崩溃)消息就丢失了。为了处里這個 那些的问题图片,随后消息系统提供了另外另一个个功能:当消息被发送出去随后 仅仅被标记为已发送情况表,当接到 consumer 不可能 消费成功的通知后才标记为已被消费的情况表。這個 太好处里了消息丢失的那些的问题图片,但产生了新那些的问题图片,首先不可能 consumer处里消息成功了随后 向 broker 发送响应时失败了,这条消息将被消费两次。第另一个那些的问题图片时,broker 前要维护每条消息的情况表,随后 每次不会 先锁住消息随后 更改情况表随后 释放锁。原本麻烦又来了,且不说要维护大量的情况表数据,比如不可能 消息发送出去但没人 收到消费成功的通知,这条消息将无缘无故指在被锁定的情况表,Kafka 采用了不同的策略。Topic 被分成了若干分区,每个分区在同一时间只被另一个 consumer 消费。这意味着每个分区被消费的消息在日志中的位置仅仅是另一个简单的整数:offset。原本就很容易标记每个分区消费情况表就很容易了,仅仅前要另一个整数而已。原本消费情况表的跟踪就很简单了。

这带来了另外另一个好处:consumer 还都后能 把 offset 调成另一个较老的值,去重新消费老的消息。这对传统的消息系统来说看起来這個 不可思议,但人太好是非常有用的,谁规定了三根消息只有被消费一次呢?

bin/kafka-topics.sh --list --zookeeper localhost:2181

Kafka允许topic的分区拥有若干副本,這個 数量是还都后能 配置的,我能 为每个topci配置副本的数量。Kafka会自动在每个个副本上备份数据,随后当另一个节点down掉时数据依然是可用的。

Kafka的副本功能不会 前要的,我能 配置只有另一个副本,原本人太好就共要 只有一份数据。

Kafka到底会不要 丢数据(data loss)? 通常不要 ,但這個 情况表下的确有不可能 会指在。下面的参数配置及Best practice列表还都后能 较好地保证数据的持久性(当然是trade-off,牺牲了吞吐量)。

block.on.buffer.full = true

acks = all

retries = MAX_VALUE

max.in.flight.requests.per.connection = 1

使用KafkaProducer.send(record, callback)

callback逻辑中显式关闭producer:close(0)

unclean.leader.election.enable=false

replication.factor = 3

min.insync.replicas = 2

replication.factor > min.insync.replicas

enable.auto.commit=false

消息处里完成随后 再提交位移

将 auto.commit.offset 设为 false,随后 在处里一批消息后 commitSync() 不可能 异步提交 commitAsync()

即:

Kafka是最初由Linkedin公司开发,是另一个分布式、支持分区的(partition)、多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性之还都后能 否实时的处里大量数据以满足各种需求场景:比如基于hadoop的批处里系统、低延迟的实时系统、storm/Spark流式处里引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。

欢迎亲戚亲戚人们人们人们同去交流,喜欢文章记得关注我点个赞哟,感谢支持!

和 MQTT 的事务定义一样不会 3 种。

(1)最多一次: 消息不要 被重复发送,最多被传输一次,但不会 不可能 一次不传输

(2)共要 一次: 消息不要 被漏发送,共要 被传输一次,但不会 不可能 被重复传输.

(3)精确的一次(Exactly once): 不要 漏传输随后 会重复传输,每个消息都传输被一次随后 仅仅被传输一次,这是亲戚亲戚人们人们人们所期望的