zoukankan      html  css  js  c++  java
  • kafka面试总结

    本文为复习期间面试总结

    从以下方面对kafka面试进行总结:基本原理架构/项目实践/生产者/消费者/协调者/存储层/控制器

    常见概念

    • Partition: kafka分区模型 每个分区都是一个有序的独立的不可变的记录序列,新的消息会不断-的追加到序列末尾,分区的offset都是从0开始。kafka只能保证消息在单个分区的有序
    • Segment:partition物理上由多个segment组成
    • Offset:偏移量 通过offset+partition+topic可以定位到唯一一条消息
    • broke:消息代理服务器 可以认为是一台独立的机器
    • Topic:消息主题
    • ConsumerGroup:消费者组
    • ISR:副本冗余[正在和主副本保持同步的备份副本 只要ISR中还有一个节点是存活的就能保证消息不丢失 主副本和备份副本都有消息,主挂可切换副]
    • AR: 所有副本[包含主副本和正在同步的副本]
    • OSR:被踢出ISR的叫OSR,当同步进度追上 会重新加入ISR

    ZK作用

    注册中心[作为共享存储保存了kafka集群和客户端的相关信息]
    一般生产环境三台起部署 且部署基数台。

    分区副本如何分配

    只有一个节点:
    所有的分区副本都会在文件存储根目录下:命名规则为 TopicName+分区序号 序号从0开始
    有多节点:
    每个节点有相等的机会分配分区的主副本。

    副本分配算法:将所有节点和分区排序
    主副本分配规则:将第i个分区分配到 第i%n个 节点上。
    从副本分配规则:将第i个分区的第k个从副本分配到第(i+k)%n 个节点上。
    

    partiton中文件存储方式

    kafka高可用的

    一般多机分布式部署 Kafka每个topic的partition有N个副本,其中N是topic的复制因子。Kafka通过多副本机制实现故障自动转移,当Kafka集群中一个Broker失效情况下仍然保证服务可用。

    kafka消息模型

    队列模型和发布订阅 kafka使用消费者组统一了上面2种消息模型。[队列1对1/订阅1对多]

    kafka为什么这么快

    写message

    1. 消息并不是直接写入磁盘,而是写入Page Chache[页缓存]。
    2. 由异步线程刷盘,消息从页缓存输入磁盘。

    读message

    1. 先找页缓存区域 如果可以找到消息,直接socket返回消息。
    2. 找不到消息此时会在磁盘上读取,并加载到page cache。

    其他:

    1. 零拷贝:指计算机操作的过程中,CPU不需要为数据在内存之间的拷贝消耗资源。而它通常是指计算机在网络上发送文件时,不需要将文件内容拷贝到用户空间(User Space)而直接在内核空间(Kernel Space)中传输到网络的方式。
    2. page cache: 放弃使用JVM管理内存,转而使用页缓存。
      • 使用JVM内存会受到GC影响。且过大的堆空间容易降低吞吐量。
      • JVM内的对象都需要保存object overhead[实例的type信息和内置monitor信息等]

    kafka follower如何与leader同步数据/kafka节点之间消息如何备份的

    leader也称为主副本 follower 也称为备份副本
    Producer在push消息到kafka时,先通过ZK找到对应Topic下Partition的主副本[leader],Producer和leader建立联系发送消息,N个replicas中。其中一个replica为leader,其他都为follower,leader处理partition的所有读写请求,与此同时,follower会被动定期地去复制leader上的数据。

    这种消息机制不能算完全的同步也不能算完全的异步

    ISR HW LEO 之间的关系/流转过程

    1. ISR 正在主副本保持备份的副本
    2. HW high wather高水位 一般指的是ISR中同步主副本的进度最慢的副本当前正在同步的消息的offset,在HW之前的消息都可以被消费者拉取到
    3. LEO log end offset 当前主副本中正在写入的消息 一般是当前分区中最后一条消息的offset+1

    当主副本有消息写入的时候,follower会主动向leader获取消息,每次读消息都会更新HW当HW大于等于LEO时候可以认为是同步完成,副本管理者会想producer报告ack确认消息保存成功。

    项目实践

    ACK 0 -1 1分别代表什么

    • [-1] 也就all 需要等待ISR中所有都同步完成
    • 1 默认的只需要等待主副本同步完成即可
    • 0 不确认就开始发送下一条消息

    kafka事务

    kafka在较高版本上支持事务,但是我们使用的版本较低,且目前业务上无硬性需求。

    消息队列丢失数据如何处理

    这个问题可以分为三个方面 生产者 消费者 消息队列

    • 生产者方面我们使用的异步回调的方式,在收到回调的时候若消息没有发送成功,我们会记录再次发送。
    • 消费者 消费者的数据丢失可以认为是提交了offset但是数据处理失败了,我们使用的手动提交在处理成功后在提交offset 不会遇到这个问题。但是要注意消息处理时间不能过长,如果处理过长还没提交offset管理者可能会认为当前消费者下线从而触发reblance
    • 消息队列数据丢失 我们在kafka配置了ack = -1 要求所有ISR都确认同步了消息才给producer发送ack 所以可以保证消息不会丢失。

    生产者

    生产者消息发送的几种方式

    同步阻塞 异步非阻塞 [都是通过send方法实现的]

    生产者如何为消息选取分区的

    若消息没有设置key loadblance写入partition。如设置了key murmur2(key) mod PartitionNum

    简单讲下生产者的工作流程

    1. 主线程将消息封装到ProducerRecord[partition/key/value/key/时间戳]
    2. client对ProducerRecord进行序列化
    3. 根据分区策略确定分区[无key轮询有key murmur2(key) mod PartitionNum]
    4. 将消息放入缓存区[每一个分区对应一个双端队列] 由sender线程将一个批次的消息batch的消息发送到对应的broker

    生产者如何批量的发送消息

    sender的作用:归类消息为每个目标节点建立一个请求

    sender线程并不真正发送客户端请求 sender线程会去遍历记录收集器中根据分区分好组的消息batches,将相同目标节点[NodeId]的batches的消息归类,为相同目标节点的[NodeId]创建一个请求发送消息。

    1. 消息放入记录收集器时会按分区进行分组,存放到对应的batches,分区队列保存了即将发送消息的批记录。

    2. sender线程可以使用单线程迭代

    消费者

    什么是管理者

    管理者是消费者组中的概念,用于对同一个消费者组中的所有消费者进行协调。

    什么是reblance

    简单来说就是消费者消费消息出现不均衡,会通过reblance达到动态平衡的过程。通常有如下几个方面

    • 消费者组订阅的主题发生变化
    • 消费者消费的分区数量出现变化
    • 消费者组中的消费者数量发生变化

    消费者什么时候会再次加入消费者组

    消费者只有在出现reblance的时候会出现再次加入消费者,分为如下步骤1.消费者准备好自身状态2.和协调者发送加入消费者组的请求3.成功加入消费者组,分配分区开始消费消息。

    2种消费模式

    消费模式可分为订阅模式和分配模式

    • 订阅模式 消费者订阅指定主题,由协调者协调消费的分区
    • 分配模式 由消费者指定消费的分区。此时协调者不参与

    我们项目中有4个分区,使用的订阅模式 设置了4个消费者。每个消费者独立消费一个分区[由协调者安排]

    交付语义

    1. 精准一次
    2. 至多一次
    3. 至少一次

    参考资料

    • kafka实战
    • kafka技术内幕
    • kafka在公司项目实践
  • 相关阅读:
    mysql索引
    springboot mybatis 后台框架平台 shiro 权限 集成代码生成器
    java 企业网站源码模版 有前后台 springmvc SSM 生成静态化
    java springMVC SSM 操作日志 4级别联动 文件管理 头像编辑 shiro redis
    activiti工作流的web流程设计器整合视频教程 SSM和独立部署
    .Net Core中的ObjectPool
    文件操作、流相关类梳理
    .Net Core中的配置文件源码解析
    .Net Core中依赖注入服务使用总结
    消息中间件RabbitMQ(一)
  • 原文地址:https://www.cnblogs.com/threecha/p/13737421.html
Copyright © 2011-2022 走看看