【Kafka】

那 Kafka 为什么这么快？如何做到这个高的性能？ 本篇文章主要从这 3 个角度来分析： 生产端 服务 消费端

通常，消息消费时候都会设置一定重试次数来避免网络波动造成的影响，同时带来副作用是可能出现消息重复。 整理下消息重复的几个场景： 生产端： 遇到异常，基本解决措施都是 重试。 场景一：lead

如何知道有消息丢失？哪些环节可能丢消息？如何确保消息不丢失？引入 MQ 消息中间件最直接的目的：系统解耦以及流量控制（削峰填谷）。怎么确保消息 100% 不丢失？

为什么选用版本 Kafka 2.7? kafka 2.7 版本还是带 Zookeeper, 2.8 之后就换了。公司目前使用的 Kafka 版本仍带 Zk

消费者正常读取数据，如图： 使用零拷贝读取数据，如图： 关于数据网络传输 Kafka这种应用必然需要大量

为了提高消费速度，多个消费者并行消费比不可少。 Kafka 允许创建消费组(唯一标识 group.id)

这里不得不提 2 个重要参数：replica.lag.max.messages 和 replica.lag.time.max.ms

每个分区对应目录的格式：topic-name_partition-number（topic-分区号）

Kafka 的 0.11.x 版本如何解决之前版本高水位机制的弊端? 高水位机制存在弊端有。Leader Epoch 解决数据不一致问题。

Kafka 的 0.11.x 版本如何解决之前版本高水位机制的弊端? 高水位机制存在弊端有：Follower 副本的高水位更新需要一轮额外的拉取请求才能实现

在高水位 HW 机制下，Leader 切换时候会发生哪些问题？ 会有两个主要问题： Leader 切换时

在高水位 HW 机制下，Leader 切换时候会发生哪些问题？ 会有两个主要问题： Leader 切换时

LEO 作用： 负责推算 Leader partition的 HW。 更新 HW：当所有的 follow. Leader 跟 Follower 的 HW 和 LEO 如何更新？

Leader 跟 Follower 的 HW 和 LEO 如何更新？ Leader 切换时发生数据丢失问题 Leader 切换时发生数据不一致问题

leader 节点宕机，但 leader 上的数据还没同步到 follower 上 此时即使选举新的 leader，但那个期间的数据已丢失

创建 Topic 时，Controller 如何实现 Leader 选举？ 删除 Topic 时，Controller 如何清理数据？

控制器组件（Controller）：是 Apache Kafka 的核心组件 主要作用是：管理和帖调整个Kafka集群

Kafka 底层数据结构存储 Kafka 底层数据存储以 partition 日志文件存储。 每一行

Kafka 如何实现高性能 IO？ 批处理：减少网络通信开销 利用操作系统 page cache 来缓存数

10亿请求电商平台 需求：电商平台，每天 10 亿请求发送到 Kafka 集群。 1. QPS 估算