Kafka常见面试题_kafka2.4 读写分离

Kafka为什么没有设计读写分离

• 读写分离适用场景
  • 说道读写分离，先说下读写分离的适用场景，读写分离目的是为了分摊主库的压力，承载更多的流量，并且适合读多写少的场景
• kafka为什么不适合读写分离
  • kafka是读写比例均衡的，并且Kafka自己也有解决负载高的方案，所有不需要读写分离
  • 增加读取链路，增加了读取延迟，原来都是消费者直接从leader那里读取数据，现在增加了follower，消费者要从follower这里读数据
  • 还要考虑主从数据一致性问题
• Kafka2.4版本之后是支持读写分离的，但并不是为了降低leader的负载，分担他的信息处理量，而是有的kafka集群分别部署在不同的机房，如果只能从leader上读取数据，需要频繁的跨机房操作，浪费网络流量

Kafka是如何解决负载高的问题，如何解决数据积压的问题

• 增加topic分区，增加消费者，增加了消费线程，为了消费更快
• 如果当天有重要的活动，可以考虑业务降级，暂时关闭不重要的业务

Kafka为什么读写效率高

• 读
  • 零拷贝机制，减少了网络IO，少了几步复制的动作
    • 非零拷贝机制
    • 零拷贝

  •  跳表的设计

  • 日志存储是稀疏索引设计

• 写

  • 内存池的设计

    • 与连接池相似，数据写入是队列前先去内存池中申请内存块，写完释放，如果申请的内存大于整个内存池的大小，则抛出异常

  • 批量发送数据，，默认200ms一次

  • 一直是往队列中写入数据，也就是内存写入，后续在进行分发多线程处理

  • 顺序写磁盘

    • 磁盘顺序写性能不低于内存随机写

    • 不需要机械寻址，这个动作很费事

Kafka生产数据的时候，如何保证数据的容错性

• 通过设置其ack策略，也就是发送数据是否需要服务端的反馈，有三个值 0、1、2
  • 0：producer不会等待border发送ack
  • 1（默认）：当leader接收消息之后发送ack
  • -1：当所有的follower都同步完消息后发送ack
• request.required.ack=0 ，将这个属性设置成0，数据生产即使发生错误，也会继续执行下去

如何保证Kafka数据不丢

• 上面说了保证容错性request.required.ack=0 ，但这样可能会丢数据，怎么保证不丢数据呢
  • request.required.ack=-1，并且副本数大于等于2，再加上如果写入失败就无限重试

如何保证Kafka数据不重复

• 上面说的失败就无限重试，那如果数据重复了怎么办
  • Kafka自带处理方式 ：  幂等性 +  ack=-1  + 事务
  • 也可以在数据下游通过程序筛选，如flink、spark，分组、按照id开窗只取第一个值

哪些场景你会选择Kafka

• 日志收集
  • 一个公司可以用Kafka收集各种服务的log，通过Kafka以统一接口服务的方式开发给各种consumer，例如发送给Hbase、ClickHouse、Hadoop等组件
• 消息队列
  • 解耦、缓存等
• 实时数据分析
  • 将某些数据存放在kafka的各个topic中，然后消费者通过这个topic中的数据做实时数据分析，当然也可以装载到hadoop中做离线数据分析
• 运营监控指标
  • 收集各种分布式应用的数据，生产各种集中操作的反馈，比如报警和报告
• 流式处理
  • 流式处理数据缓冲层

Kafka分区的目的

• 对于整个集群来说，实现负载均衡
• 对于消费者来说，提高并发度

Kafka是如何高效存储的

• Kafka把topic中的parition大文件分成多个小文件，通过多个小文件，就容易定期清除已经消费完的数据，减少磁盘的占用，并且kafka是顺序写磁盘，写入时需要加载磁盘文件，文件太大肯定性能不好
• 通过索引信息可以快速定位message和确定返回信息大小
• 通过稀疏索引文件存储，可以大幅度降低index元数据文件占用空间

Kafka的存储结构

• Zookeeper
  • Kafka2.8版本之后不再需要ZK管理元数据了
  • ZK负责管理维护Kafka集群，管理Kafka相应的元数据，主要包括：border节点信息、kafka集群信息、偏移量信息、分区状态信息、分区副本配置方案信息。
  • 同时通过ZK我们能够很方便的对Kafka集群进行水平扩展以及数据迁移
• topic
  • 主题，类似关系型数据库的表，同一种类型的数据放在一个topic中
• Partition
  • 分区，topic中的数据被分为一个或多个partition，partition内的数据是分区内有序的，但全局是不能保证顺序的，也就是局部有序
  • 如果有3个border，1个topic，每个分区两个副，不同的副本存储在不同的Borker
  • 分区能增不能减，副本能增能减
    • 如果分区减少了数据没地方放，直接删除会少数据，追加到别的分区就破坏了kafka局部有序的原则
  • 分区域存储的方式
    • 每个分区在磁盘上会对应一个文件夹，分区的命名规则为：主题名称-分区编号
    • 
    • 日志分段存储
      • kafka的数据底层文件存储格式都是以.log结尾，我们称之为日志文件，每条数据都可以称之为message，每条message的新增都是追加到.log文件的末尾
      • 每个.log文件达到1G（默认）大小后就生成3个文件
        • 
        • .index文件，物理索引文件，存储message的offset与message的物理位置
          • 采用稀疏索引的方式存储，每写进4k的message，就会在index文件中记录一条索引
          • 这里如果不用稀疏索引的话，如果从头开始消费，想获取offset是20000的那条message，那么就要从头开始遍历，直到20000位置，稀疏索引缩小搜索范围，并且减少索引锁占用的空间
          • 找到相应的索引位置后，在利用二分查找法找到offset所对应的数据
        • .log文件，数据存储文件
        • .timeindex文件，时间戳索引
      • 由于kafka是顺序写磁盘的，message是追加到文件末尾的，写磁盘时要先加载文件，如果磁盘文件太大，性能肯定不好
      • 如上面黑色的图片，文件名是以00000000000136440991 为前缀，代表这个文件内的 message 的 offset 是以 00000000000136440991 开头的，依次递增，直到文件大小达到 1G

Kafka生产者与消费者

• 怎么优化Producer的生产速度
  • 增加线程
  • 增加producer
  • 提高batch.size
  • 增加parition数
• Producer发布消息时可以发布到指定的Partition中，也可以随机的
  • round-robin 做简单的负载均衡
  • 根据消息的某个关键字来分区（hash、随机等），将消息发布到指定topic的指定分区内
• 消费者组
  • 同一个topic中的一个消息，只能被同一个消费者组中的一个消费者消费，但多个消费者组可以同时消费这个消息
  • 同一个消费者组中，consumer数量如何选择？
    • 由于不能两个consumer同时消费一个parition，所以consumer不能多于partition
    • 如7个consumer，10个parition，这样会导致parition中的数据被取的不均匀，所以如果说consumer比partition少时，最好是整数倍，也就是 partition是10个，consumer是 5个或 2个 或 10个

Kafka中的Partition数量怎们确定

• 根据业务特点设置分区数量
  • 自定义分区，将同一类型的数据划分到一个分区内，如按省份划分，按性别划分等
• 也可根据并行度设置
  • 如果业务上没有上面那样的划分需求，可以根据后续数据处理的并行度来设置，但要慎重考虑，因为设置好数量后不能变小，增加分区也可能会产生shuffle
• 压力测试，根据吞吐量设置
• 分区是否越多越好
  • 好处
    • 虽说分区可以提供更高的吞吐量，提高消费的并行度
  • 不好处
    • 分区多了磁盘上的目录自然多
    • partition副本复制的时间也会变长
    • 内存需要的多，分区多了，consuomer少，如1000个分区，2个consuomer，那么每个consumer就需要记录500个分区信息，内存需要的多了
• 分区数建议3-10个

Kafka服务器所能接收的最大message是多少

• 默认是1000000字节，但生产中建议调成10M

Kafka的ISR副本同步队列

• ISR中包含leader和follower，如果leader挂掉了，会在从ISR队列中选出一个leader
• 加入ISR队列的条件有两点，下面这两个参数决定一台服务器是否可以加入ISR队列
  • 延迟条数（0.10版本后移除，防止服务频繁进入队列）
  • 延迟时间
• 任意一个维度超出范围这个Follower就会被移除ISR队列，加入到OSR队列，新加入的Follower也会进入这个OSR队列