Kafka06-进阶-尚硅谷 - 实践
3-Kafka进阶
文章目录
- 3-Kafka进阶
- @[toc]
- 3.1 Controller选举
- Controller？就是3.1.1 什么
- 3.1.2 如何选出Controller？
- 3.1.3 脑裂与epoch
- 3.2 Broker上下线感知
- 3.2.1 监听机制
- 3.3 数据偏移量定位
- 3.3.1 分区物理结构
- 3.3.2 稀疏索引
- 3.4 Topic删除
- 3.5 日志清理/压缩
- 3.5.1 时间/大小删除（delete）
- 3.5.2 日志压缩（compact）
- 3.6 页缓存（PageCache）
- 3.7 零拷贝
- 3.8 顺序写日志
- 3.9 Linux集群部署（3节点）
- 3.9.1 规划
- 3.9.2 关键脚本
- 3.10 Kafka-Eagle监控
- 3.11 KRaft模式（无ZooKeeper）
- 3.11.1 优势
- 3.11.2 部署要点
文章目录
- 3-Kafka进阶
- @[toc]
- 3.1 Controller选举
- Controller？就是3.1.1 什么
- 3.1.2 如何选出Controller？
- 3.1.3 脑裂与epoch
- 3.2 Broker上下线感知
- 3.2.1 监听机制
- 3.3 数据偏移量定位
- 3.3.1 分区物理结构
- 3.3.2 稀疏索引
- 3.4 Topic删除
- 3.5 日志清理/压缩
- 3.5.1 时间/大小删除（delete）
- 3.5.2 日志压缩（compact）
- 3.6 页缓存（PageCache）
- 3.7 零拷贝
- 3.8 顺序写日志
- 3.9 Linux集群部署（3节点）
- 3.9.1 规划
- 3.9.2 关键脚本
- 3.10 Kafka-Eagle监控
- 3.11 KRaft模式（无ZooKeeper）
- 3.11.1 优势
- 3.11.2 部署要点
3.1 Controller选举
3.1.1 什么是Controller？
- Kafka集群唯一“大脑”，负责分区Leader选举、副本迁移、Topic创建/删除等全局协调工作。
3.1.2 如何选出Controller？
- 所有Broker抢先在ZooKeeper创建
/controller临时节点，成功者即为Controller；其余Broker监听该节点变化。
3.1.3 脑裂与epoch
- 网络抖动可能导致旧Controller“复活”。Kafka为每次选举递增epoch（纪元），Broker发现epoch小于当前值即主动退位，避免脑裂。
3.2 Broker上下线感知
3.2.1 监听机制
- Controller启动时在ZK注册大量Watcher，关键路径：
/brokers/ids。 - Broker上线：创建临时节点
/brokers/ids/{brokerId}；Controller立即同步元数据。 - Broker下线：会话超时节点消失；Controller将该Broker上的Leader分区重新选举并通知全网。
3.3 材料偏移量定位
3.3.1 分区物理结构
- 每个Partition→多个Segment记录（.log/.index/.timeindex）。
- 文件名=该段起始offset，固定20位数字。
3.3.2 稀疏索引
- 默认每写4KB（
log.index.interval.bytes）才在.index写一条entry：相对offset(4B)+物理position(4B)。 - 查找时先跳跃表定位Segment，再用二分找不大于目标offset的索引项，顺序扫描.log。
3.4 Topic删除
| 方式 | 场景 | 关键步骤 |
|---|---|---|
| 快速配置 | 允许停机 | delete.topic.enable=true+kafka-topics.sh --delete |
| 策略删除 | 长期保留 | 设置log.cleanup.policy=delete+时间/大小阈值 |
| 手动删除 | 不能改配置 | 删除ZK元数据/brokers/topics/{topic}+各Broker本地日志目录 |
3.5 日志清理/压缩
3.5.1 时间/大小删除（delete）
- 全局阈值：
log.retention.hours=168、log.retention.bytes=-1。 - Segment级按最大时间戳判断，只要有一条未过期即保留整段。
3.5.2 日志压缩（compact）
log.cleanup.policy=compact：相同key仅保留最新记录，用于状态类Topic。
3.6 页缓存（PageCache）
- 生产者顺序写→先写OS页缓存，由内核异步刷盘；消费者读命中缓存即内存级速度。
- 参数
log.flush.interval.messages/ms可强制同步刷盘，但推荐用多副本保可靠而非同步刷盘。
3.7 零拷贝
- 消费/副本同步时，通过
sendfile系统调用，数据直接页缓存→网卡，省去用户态与内核态来回拷贝，单磁盘顺序读可达600MB/s。
3.8 顺序写日志
- 仅追加写ByteBuffer，满刷盘；避免随机寻址，性能远高于随机写（600MB/s vs 100KB/s）。
3.9 Linux集群部署（3节点）
3.9.1 规划
| 节点 | IP | 角色 |
|---|---|---|
| kafka-broker1 | 192.168.10.101 | ZK+Kafka |
| kafka-broker2 | 192.168.10.102 | ZK+Kafka |
| kafka-broker3 | 192.168.10.103 | ZK+Kafka |
3.9.2 关键脚本
xsync：循环rsync文件到各节点。zk.sh start|stop|status：一键启停ZK集群。kfk.sh start|stop：一键启停Kafka集群。cluster.sh start|stop：先启ZK再启Kafka，关闭时顺序相反并等待Kafka进程归零。
3.10 Kafka-Eagle监控
- 依赖MySQL存储指标；修改
kafka-server-start.sh增加JMX端口9999。 - 配置
system-config.properties后，ke.sh start启动，访问http://broker1:8048（admin/123456）。
3.11 KRaft模式（无ZooKeeper）
3.11.1 优势
- 单进程部署、元数据自管理；扩展性提升至百万分区；Controller由配置静态指定，避免动态选举抖动。
3.11.2 部署要点
- 解压并重命名
kafka-kraft。 - 修改
config/kraft/server.properties：process.roles=broker,controllernode.id=1/2/3（各节点唯一）controller.quorum.voters=1@broker1:9093,2@broker2:9093,3@broker3:9093
- 生成集群ID：
bin/kafka-storage.sh random-uuid，再format所有节点。 - 启停脚本
kfk2.sh与ZK版类似，仅替换路径与配置文件。