当前位置:   article > 正文

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

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队列
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/IT小白/article/detail/629359
推荐阅读
相关标签
  

闽ICP备14008679号