Daily Study

更新: 3/7/2026 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

Kafka深度学习

#暑期实习

Kafka Broker 原理

Kafka Broker 的原理拆解为 存（存储设计）、管（元数据管理）、传（网络通信）三个核心维度。

一个Kafka集群由多个Broker节点组成，Broker是一个独立的服务器进程，集群中会有一个Controller，作为集群的大脑，负责管理分区状态，Leader选举，集群元数据管理。架构层面采用基于Raft协议的KRaft架构

存储原理

• 顺序写磁盘：机械硬盘（HDD）的随机读写非常慢（因为磁头要寻道），但顺序读写非常快（接近内存速度）。Broker 将消息追加写（Append Only）到日志文件（Log Segment）的末尾。它不修改已写入的数据，也不支持随机插入。
• 日志分段(Log Segment)：结构：Topic -> Partition -> Log -> Segment。一个 Partition 在物理上被切分成多个 Segment 文件（默认 1GB 一个）。
• 稀疏索引：Kafka 的索引不是每一条消息都记，而是每隔 4KB 记一条。空间换时间，牺牲了一点 CPU 扫描时间，极大地节省了索引占用的内存空间（Page Cache）

高可用原理

主要是ISR(In-Sync Replicas)和HW(High Watermark)

• Replica (副本) 机制：每个 Partition 有一个 Leader 和多个 Follower。Leader处理所有的读写请求，Follower唯一的任务是从Leader拉取（Fetch）数据同步
• ISR(In-Sync Replicas)：只有跟得上 Leader 速度的副本集合，才叫 ISR。在发生选举过程中，并不是所有 Follower 都有资格参与 Leader 选举。如果一个 Follower 卡住了或者挂了，会被踢出 ISR，放入 OSR (Out-of-Sync)
• HW(High Watermark) 与 LEO (Log End Offset)：LEO表示日志末端偏移量。表示“我写入了多少数据”。每个副本的 LEO 可能不一样。HW = Min(ISR 中所有副本的 LEO)保证数据一致性。即使 Leader 挂了，只要 HW 之前的数据，在 ISR 里一定都有，不会丢失。

性能优化：零拷贝

• 传统 Read/Send：磁盘 -> 内核 Buffer -> 用户 Buffer (应用层) -> 内核 Socket Buffer -> 网卡。涉及 4 次拷贝，4 次上下文切换。
• Kafka Zero Copy：Broker 使用 Linux 的 sendfile 系统调用。数据路径：磁盘 -> Page Cache (内核) -> 网卡。数据根本不经过 Broker 应用程序的内存

面试回答

“Kafka Broker 是集群的核心存储和传输节点。我对它的理解主要集中在高性能存储和分布式一致性两方面。

1. 在存储层面：Broker 极致利用了磁盘特性。
   • 利用 顺序写 (Sequential Write) 规避磁盘寻道开销。
   • 利用 稀疏索引 (Sparse Index) 和 分段日志 (Segment) 实现快速定位。
   • 最重要的是利用 Page Cache 和 Zero Copy (sendfile) 技术，让数据直接在内核态流转，极大降低了 CPU 和内存开销。
2. 在分布式层面：Broker 通过 ISR (同步副本集合) 机制平衡了可用性与一致性。
   • 引入 HW (高水位) 概念，确保了即使 Leader 宕机，已 Commit 的数据也不会丢失。
   • 新的 KRaft 架构去除了 ZooKeeper 依赖，通过 Raft 协议在 Broker 内部管理元数据，解决了大规模集群元数据同步的瓶颈。

Kafka Broker 堆积

Kafka 堆积本质上是：生产速度 > 消费速度。整个处理思路应当是：先止血（应急），再查因（定位），后根治（优化）。

Step1：定位瓶颈

• 看范围：是所有分区都堆积（系统性瓶颈。消费者整体处理能力不足，或下游（DB/Redis）挂了），还是个别分区堆积（数据倾斜 。某个 Key (如大客户 ID) 过于集中）
• 看消费者状态：
  • CPU 高 + 堆积：业务逻辑太重（计算密集型），或者陷入死循环
  • CPU 低 + 堆积：I/O 阻塞（下游 DB 慢、网络慢、锁竞争）
  • Rebalance 频繁：消费者频繁重启或超时，导致无法稳定消费

Step2：紧急处理方案

• Partition 数量 > Consumer 数量：直接增加 Consumer数量，直到相等，利用剩余的并行度
• Consumer 数量 = Partition 数量：单纯加机器没用了，可以使用临时 Topic 分流，创建一个临时的 Topic_Temp，配置 10/20 倍 的 Partition 数量（例如原 Topic 10 个分区，新的搞 100/200 个）然后增添一些搬运消费者，把原先Topic_Origin 读出来，快速转发写入 Topic_Temp，然后部署新的消费集群，来订阅Topic_Temp，达到削峰的效果

Step3：根因分析与代码优化

• 消费端优化（90%的问题所在）：改为批量消费（例如不要来一条插一条 DB，攒够 500 条或 100ms，拼成一个 Batch Insert SQL 批量入库）。增加单机并发（Kafka 的 Partition 限制了进程数，但没限制线程/协程数，Consumer 收到消息后，不要自己处理，扔给本地的一个 Worker Pool（Channel + Goroutines）来处理，但是这会导致 Offset 提交复杂化（可能丢数据或重复消费），需要手动维护 Offset 或保证幂等性。）
• Broker段优化（很少见）：增加磁盘 I/O 或 系统内存（Page Cache）
• 生产端：做一些限流操作，如果是因为上游搞促销、遭攻击导致流量突增，必须在源头或网关层限流，保护后端。

总结：面对 Kafka 堆积，我的处理思路是分级响应：

1. 止血：首先看下游 DB 是否正常。如果 DB 没挂，且 Partition 还没被填满，立刻扩容消费者。如果 Partition 满了，我会采用临时 Topic 分流方案，起一批纯转发的 Consumer 把数据搬运到 100 个分区的新 Topic，再用 100 个 Worker 并行消费。
2. 排查：通过监控看是计算密集（CPU高）还是IO密集（CPU低）。如果是 IO 慢，通常是数据库瓶颈。
3. 优化：
   • 代码层面，我会引入 Go Worker Pool 在单机内部并行处理，并改用 Batch Insert 降低 DB 压力。
   • 在 SCF 场景下，我会利用 Batch Window 聚合请求，并严格限制最大并发数，防止 Serverless 的无限扩容能力把下游数据库打崩。

Kafka是如何实现高吞吐率的

Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：

• 顺序读写：partition顺序读写，充分利用磁盘特性
• 零拷贝
• 文件分段
• 批量发送
• 数据压缩

其中针对零拷贝的原理具体如下：

• 使用了mmap映射。Producer生产的数据持久化到broker，采用mmap文件映射，实现顺序的快速写入。mmap映射简单描述其作用就是：将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上（操作系统在适当的时候）因此mmap有一个缺陷是不可靠，因为mmap中的数据通常不是真正的立马就写到硬盘中。
• 使用了零拷贝 sendfile(in,out)。Customer从broker读取数据，采用sendfile，将磁盘文件读到OS内核缓冲区后，直接转到socket buffer进行网络发送。sendfile的原理是数据直接在内核完成输入和输出，不需要拷贝到用户空间再写出去。例如linux中磁盘数据通过 DMA 拷贝到内核态 Buffer 后，直接通过 DMA 拷贝到 NIC Buffer(socket buffer)，无需 CPU 拷贝。

针对零拷贝：除了传统的 sendfile，我在做 eBPF 项目时也接触过类似的零拷贝思想。 比如 eBPF Map 和 XDP (eXpress Data Path)。 传统网络包处理需要把包从网卡拷贝到 sk_buff（内核协议栈），再拷贝到用户态。 而 XDP 允许我们在网卡驱动层直接处理数据包（Direct Packet Access），甚至在数据包还没生成 sk_buff 之前就丢弃或转发，这实现了极致的零拷贝，非常适合做高性能防火墙或 DDoS 防御

Mysql索引相关

Mysql索引优化/失效

原来问索引优化可以类比到索引失效的场景~

基本规则：查询的条件字段尽量用索引字段

• and/or条件相连：and条件相连，有一列有索引就会命中索引，加快查询速度；or条件相连，所有列都有索引才能命中索引，加快查询速度；
• like语句的前导模糊查询不能使用索引：select * from doc where title like '%XX '；
• union、in、or 都能够命中索引，建议使用 in
• 负向条件查询不能使用索引：负向条件有：!=、<>、not in、not exists、not like 等。可以优化成 in 查询
• 联合索引最左前缀原则
• 不能使用索引中范围条件右边的列（范围列可以用到索引），范围列之后列的索引全失效：索引最多用于一个范围列，如果查询条件中有两个范围列则无法全用到索引，范围条件有：<、<=、>、>=、between等
• 不要在索引列上面做任何操作（计算、函数），否则会导致索引失效而转向全表扫描
• 强制类型转换会全表扫描：字符串类型不加单引号会导致索引失效，因为mysql会自己做类型转换,相当于在索引列上进行了操作，例如 select * from user where phone=13800001234，应该 phone = '13...'
• 更新十分频繁、数据区分度不高的列不宜建立索引
• 利用覆盖索引来进行查询操作，避免回表，减少select * 的使用
• 索引不会包含有NULL值的列:只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时，尽量使用not null 约束以及默认值
• is null, is not null无法使用索引:
• 如果有order by、group by的场景，请注意利用索引的有序性：order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现file_sort 的情况，影响查询性能。例如对于语句 where a=? and b=? order by c，可以建立联合索引(a,b,c)。
• 使用短索引（前缀索引）：对列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果该列在前10个或20个字符内，可以做到既使得前缀索引的区分度接近全列索引，那么就不要对整个列进行索引。因为短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作，减少索引文件的维护开销。可以使用count(distinct leftIndex(列名, 索引长度))/count(*) 来计算前缀索引的区分度。但缺点是不能用于 ORDER BY 和 GROUP BY 操作，也不能用于覆盖索引
• 利用延迟关联或者子查询优化超多分页场景：这里说的是具体查询很多页中的某一页，可以利用offset，先快速定位需要获取的id段，然后再关联：select a.* from 表1 a,(select id from 表1 where 条件 limit100000,20 ) b where a.id=b.id；
• 如果明确知道只有一条结果返回，limit 1 能够提高效率
• 单表索引建议控制在5个以内
• SQL 性能优化 explain 中的 type：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts 最好
  • consts：单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。
  • ref：使用普通的索引（Normal Index）。
  • range：对索引进行范围检索。
  • 当 type=index 时，索引物理文件全扫，速度非常慢。
• 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引

Mysql索引用/不用

使用索引：

• 主键自动建立唯一索引。
• 经常作为查询条件在WHERE或者ORDER BY 语句中出现的列要建立索引。
• 查询中与其他表关联的字段，外键关系建立索引。
• 经常用于聚合函数的列要建立索引，如min()，max()等的聚合函数。

不用索引：

• 经常增删改的列不要建立索引。
• 有大量重复的列不建立索引。
• 表记录太少不要建立索引，因为数据较少，可能查询全部数据花费的时间比遍历索引的时间还要短，索引就可能不会产生优化效果 。