【Kafka学习-3】Broker相关

本文内容整理自尚硅谷Kafka3.0教程

ZooKeeper

• ZooKeeper用于辅助kafka，保存kafka相关信息（）
• 之后的版本逐渐走向去ZooKeeper化
  
• /kafka/bokers
  • ./ids 哪些服务器
  • topics 主题/分区信息
    • ./state Leader，isr
• /kafka/consumers
  • 消费者相关信息，如offset
• /kafka/controller
  • 记录了用于选择的controllerId

Kafka-Kraft模式

​ Kafka 现有架构， 元数据在 zookeeper 中， 运行时动态选举 controller， 由controller 进行 Kafka 集群管理。 kraft 模式架构（实验性）， 不再依赖 zookeeper 集群，而是用三台 controller 节点代替 zookeeper， 元数据保存在 controller 中， 由 controller 直接进行 Kafka 集群管理。
​ 这样做的好处有以下几个：

• Kafka 不再依赖外部框架， 而是能够独立运行
• controller 管理集群时， 不再需要从 zookeeper 中先读取数据， 集群性能上升
• 由于不依赖 zookeeper， 集群扩展时不再受到 zookeeper 读写能力限制
• controller 不再动态选举， 而是由配置文件规定。 这样我们可以有针对性的加强
• controller 节点的配置， 而不是像以前一样对随机 controller 节点的高负载束手无策。

Broker工作流程

• 初始化
  • broker在zk中注册
  • broker中的各个controller争夺zk中的controller节点（谁先启动），优先注册的成为本次负责选举的controller
  • controller监听各个节点，并选举broker
    • 选举策略
      • 按AR（Assigned Replicas）中的顺序，依次轮询ISR中的节点
      • 第一个找到存活的设为Leader
  • 选举完成后，将节点信息上传到zk
  • 其他controller从zk中同步节点信息
• 故障处理 （某个Leader挂了）
  • controller监听节点变化，发现Leader故障
  • 获取ISR，按照AR排序依次轮询，存活的设为新Leader 确认下AR含义
  • 更新zk保存的信息

Leader / Follower 故障处理

• Follower故障处理
  
• Leader故障处理
  
• HW之前的对消费者可见

副本分配

// TODO

文件存储

• 每个partition对应于一个log文件， 该log文件中存储的就是Producer生产的数据，Producer生产的数据会被不断追加（不会修改）到该log文件末端。

• 为防止log文件过大导致数据定位效率低下， Kafka采取了分片和索引机制，将每个partition分为多个segment。 每个segment包括： “.index”文件、 “.log”文件和“.timeindex”等文件。 这些文件位于一个名字为“topic名称+分区序号”的文件夹下。

  • .log 日志文件，存消息
  • .index 索引文件，存日志文件的索引
  • 命名：以当前segment的第一条消息的offset为名字

• 如何在log文件中根据offset快速定位Record

  

• 删除策略

  • 指删除过期文件
    • 基于时间 和 基于大小 两种方式

• 日志压缩

  • log.cleanup.policy = compact 开启

  • 同Key不同value保留最后的版本

  • 可能会导致乱序，所以最好针对不考虑顺序的数据（如提交的offset）

    

高效读写

• kafka集群为分布式架构，并行度高

• 顺序写入log，后面只能追加数据

• 读数据的.index用稀疏索引，定位快

• 页缓存 无拷贝 //TODO

  • kafka broker应用层不考虑数据存储，只负责交互。broker和生产者/消费者的数据交互都是交给操作系统底层的页缓存进行。

  • 一般情况是：磁盘- 系统内核 - 应用程序缓存 - 网卡

  • Kafka：系统内核 - 网卡