kafka常用知识

kafka常用知识点总结，初学者可以使用，也可面试前进行温习。

kafka

• producer
  • 性能调优
    • 多线程
    • 多producer
    • batch提交
  • 防止数据丢失
    • ACK
      • 0
        • 完全异步
      • 1
        • leader确认即可
      • -1
        • leader确认&follower同步完成
  • 数据生产过程
    • Producer发送消息到Topic时，分配partition的算法如下： 1.如果指定了一个partition，那么直接使用指定的partition 2.如果没有指定partition，但是指定了key，那么会根据key进行哈希，分配到对应的partition中 3.如果partition和key都没指定，会使用round-robin算法进行分配
• consumer
  • consumer group
    • rebalance
      • 对于一个Consumer Group，可能随时都有Consumer加入或者退出这个Consumer Group，Consumer列表的变化势必会引起partition的重新分配。这个为Consumer分配partition的过程就被称为Consumer Rebalance。Consumer Group订阅的任何一个Topic出现分区数量的变化，也会导致rebalance。
      • 真正的Consumer Rebalance行为是由Consumer Group Leader执行的。Group Leader首先向Coordinator获取Group中的Consumer成员列表，然后根据Rebalance策略，将partition分配给Consumer Group中的成员，再将分配结果告知Coordinator。最后，Coordinator将partition分配结果通知给每一个Consumer。在Consumer Rebalance的过程中，所有的Consumer都不允许消费消息。
      • rebalance策略
        • Range策略
          • 1.对一个topic中的partition进行排序 2.对消费者按字典进行排序 3.然后遍历排序后的partition的方式分配给消费者
        • RoundRobin策略
          • RoundRobin策略和Range策略类型唯一的区别就是Range策略分配partition时，是按照topic逐次划分的。而RoundRobin策略则是将所有topic的所有分区一起排序，然后遍历partition分配给消费者。
    • 原则
      • 一个consumer group中数据不能重复消费
      • 一个partition数据只能被一个consumer group中的一个consumer消费
  • 性能调优
    • 多consumer
  • 防止重复消费&无消费
    • offset维护
  • API
    • high level api
      • kafka通过zookeeper维护consumer的消费的offset
    • low level api
      • 用户自己维护consumer的offset
  • 消费流程
    • 1.通过文件名前缀数字x找到该绝对offset 对应消息所在文件 2.offset-x为在文件中的相对偏移 3.通过index文件中记录的索引找到最近的消息的位置 4.从最近位置开始逐条寻找
• broker
  • controller选举
• topic
  • partition
    • key value设计partition设计及producer使用
    • replication
      • 定义数据副本数（1 leader+n follower）
    • AR=ISR+OSR
      • 副本同步数据和leader数据的时间差和条数
    • leader选举
      • 不允许数据丢失情况下只选取ISR中的partition
      • 可容忍数据丢失情况下可以选取OSR中的partition
    • 数据存储格式
      • 数据文件及作用
        • .index
          • 数据索引文件
        • .log
          • 数据文件
        • .timeindex
          • 时间索引文件
        • leader-epoch-checkpoint
          • leader-epoch-checkpoint中保存了每一任leader开始写入消息时的offset 会定时更新 follower被选为leader时会根据这个确定哪些消息可用
      • 数据留存策略
        • 删除
          • 根据整个topic数据大小
          • 根据数据存储时间（默认7天）
          • 根据起始位移维度
            • 可手动设置
        • 压缩
          • 相同key的value只保存一个 压缩过的是clean 未压缩的dirty 压缩之后的偏移量不连续 未压缩时连续。
      • 数据存储压缩
    • 数据管理
      • HW
        • AR集合中最大offset
      • LEO
        • 所有partition共同的最大offset
      • LSO
        • 所有partition共同最小的logStartOffset
      • LW
        • AR集合中最小的logStartOffset值
  • 创建和删除
    • 创建topic
      • 在zk上/brokers/topics/下节点 kafkabroker会监听节点变化创建主题
    • 删除topic
      • 调用脚本删除topic会在zk上将topic设置待删除标志，kafka后台有定时的线程会扫描所有需要删除的topic进行删除
• 实现transaction
  • 幂等性
    • 防止生产者重复生产（引入producerID和sequence Number）
      • PID
        • 每个新的Producer在初始化的时候会被分配一个唯一的PID，这个PID对用户是不可见的。
      • Sequence Number
        • 对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。Broker端在缓存中保存了这seq number，对于接收的每条消息，如果其序号比Broker缓存中序号大于1则接受它，否则将其丢弃。这样就可以实现了消息重复提交了。
  • TransactionId
    • 不同生产实例使用同一个TransactionId表示是同一个事务，可以跨Session的数据幂等发送。当具有相同Transaction ID的新的Producer实例被创建且工作时，旧的且拥有相同Transaction ID的Producer将不再工作，避免事务僵死。
• 使用zookeeper部分
• 使用场景
  • 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
  • 发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
• 特性
  • 读写分离
    • 不支持（kafka是主写主读）
      • 数据一致性问题
      • 数据延时问题
  • 延迟队列
    • 自定义时间轮
• 集群规划
  • 根据集群的机器数量和需要的吞吐量来决定适合的分区数。 单个Partition的磁盘占用最大不超过100GB；单节点上Partition数目不超过3000；整个集群的分区总数不超过10000。
• 使用优点
  • 缓冲和削峰
    • 上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
  • 解耦和扩展性
    • 项目开始的时候，并不能确定具体需求。消息队列可以作为一个接口层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
  • 冗余
    • 可以采用一对多的方式，一个生产者发布消息，可以被多个订阅topic的服务消费到，供多个毫无关联的业务使用。
  • 健壮性
    • 消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进行。
  • 异步通信
    • 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
• 性能优点
  • Cache Filesystem Cache PageCache缓存
  • 顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
  • Zero-copy 零拷技术减少拷贝次数
  • Batching of Messages 批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
  • Pull 拉模式 使用拉模式进行消息的获取消费，与消费端处理能力相符。